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1.  INTRODUCTION 


1.1  MISSION 

The  objective  of  the  Air-Mobile  Ground  Security  and  Surveillance  System  (AMGSSS)  project  is 
to  develop  a  system  that  can  rapidly  position  remotely  operated  ground  sensors  at  locations  of  opera¬ 
tional  interest  and  to  provide  information  obtained  by  those  sensors  back  to  the  operator.  AMGSSS 
exploits  the  capabilities  of  small,  remotely  operated,  vertical-take-off-and-landing  (VTOL)  ducted- 
fan  aircraft  to  provide  mobility  to  the  sensor  payload.  These  platforms  can  be  operated  effectively 
over  the  low-bandwidth  tactical  radio  data  links  required  by  military  users. 


1.2  BACKGROUND 

The  AMGSSS  concept  grew  from  the  Naval  Command,  Control  and  Ocean  Surveillance  Center 
(NCCOSC)  RDT&E  Division's  (NRaD’s)  experience  with  the  Ground  Air  Telerobotic  System 
(GATERS)  program  (reference  1 ),  initiated  in  1986  by  the  U.S.  Marine  Corps.  NRaD  (then  the 
Naval  Ocean  Systems  Center  [NOSC])  was  the  principal  development  agent  on  the  system.  GAT¬ 
ERS  consisted  of  a  land-based.  Tele-Operated  Vehicle  (TOV)  and  the  Airborne  Remotely  Operated 
Device  (AROD).  The  TOV  was  developed  to  perform  remote  reconnaissance/surveillance  with 
direct  fire  and  target  designation/ranging  capabilities.  The  TOV  was  based  on  a  High-Mobility- 
Multi-Wheeled-Vehicle  (HMMW'V)  platform  (reference  2)  for  which  AROD  provided  airborne 
reconnaissance  and  surveillance.  Experience  with  the  TOV  demonstrated  the  value  of  remotely 
operated  reconnaissance  systems  and  also  demonstrated  that  a  full-time  operator  and  high-bandwidth 
data  link  are  required  for  effcctis  e  mobility.  The  TOV  used  a  fiber-optic  communications  link  to  pro¬ 
vide  the  required  bandwidth  in  non-line-of-sight  situations.  The  military  users  did  not  want  to  be 
encumbered  with  the  fiber-optic  tethers  and  preferred  that  one  operator  be  able  to  supervise  several 
remote  systems. 


Figure  1.  Airborne  Remote 
Observation  Device  (AROD). 


The  AROD,  figure  1,  was  a  ducted-fan  VTOL  air  vehicle 
that  could  easily  translate  through  the  air  and  provide  aerial 
surveillance.  The  AROD  was  controlled  from  a  portable 
ground-control  station  over  a  fiber-optic  data  link,  with  a 
radio  control  link  as  a  backup.  AROD  had  limited  flight 
endurance  and  payload  capabilities. 

The  AMGSSS  concept  combines  the  rapid  mobility  and 
low-data-rate  control  aspects  of  VTOL  platforms  with  the 
long-endurance  surveillance  capabilities  of  the  unmanned 
ground  vehicles. 

1.3  PROGRAM  SPONSORSHIP  AND  MANAGEMENT 

The  AMGSSS  program  has  been  managed  by  the  Physi¬ 
cal  Security  Equipment  Management  Office  (PSEMO), 

Ft.  Belvoir,  VA,  and  sponsored  by  the  Office  of  the  Under¬ 
secretary  of  Defense  (Acquisition,  Tactical  Systems/Land 
Systems).  NRaD  is  supporting  PSEMO  as  the  program 
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technical  direction  and  development  agent.  The  system  was  envisioned  as  supporting  tactical  security 
and  force  protection  requirements.  For  fiscal  year  (FY)  1996  this  work  was  sponsored  by  the 
Defense  Nuclear  Agency  (DNA)  (now  called  the  Defense  Special  Weapons  Agency  [DSWA])  under 
DNA  MIPR  96-2102  and  Work  Unit  82307  and  by  PSEMO  under  MIPR  66041. 
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2.  OPERATIONAL  CONCEPT 


AMGSSS  will  support  light  and  heavy  early  entry  forces  with  a  rapidly  deployable,  highly  mobile 
sensor  system  that  provides  extended-range  surveillance,  detection,  and  identification  for  force 
protection  and  tactical  security  throughout  the  battlespace.  AMGSSS  will  give  combat,  combat-sup- 
port,  and  combat-service-support  battalion/company/combat  team  commanders  near-real-time  situa¬ 
tional  awareness.  It  will  expand  the  areas  of  the  commander’s  influence,  reduce  hazards  to  the  sol¬ 
dier,  and  provide  early  warning  and  assessment  of  enemy  threats  (reference  3). 

The  system,  figure  2,  consists  of  three  air¬ 
mobile,  remote  ground  sensor  units,  a 
HMMWV-mounted  base  station,  and  a 
3/4-ton  trailer  for  ground  transport  of  the 
Air-Mobile  Platforms  (AMPs).  The  trailer 
will  be  towed  by  the  HMMWV.  The  AMPs 
are  small  (less  than  300  lb  and  6-ft  diameter) 
units  that  transport  the  sensor  payload  to  the 
operational  sites.  The  units  do  not  perform 
aerial  observation,  but  simply  move  the  sen¬ 
sors  from  one  ground  location  to  another 
where  they  perform  extended  observation. 
AMGSSS  will  allow  the  field  commander  to 
quickly  extend  his  information-gathering 
perimeter  out  10  km.  The  three  platforms 
can  be  deployed  as  a  barrier  to  detect  intru¬ 
sions  or  deployed  independently  to  monitor 
assets,  critical  routes,  or  choke  points.  The 
sensors  provide  long-term  surveillance  with¬ 
out  putting  personnel  at  undue  risk.  The  unit’s  rapid  mobility  and  insensitivity  to  intervening  terrain 
allow  it  to  be  quickly  relocated  to  operationally  relevant  locations  if  the  threat  area  moves. 

The  AMGSSS  system  will  be  operated  by  three  military  personnel.  Upon  arriving  at  the  deploy¬ 
ment  site,  two  soldiers  will  off-load  the  AMPs  from  their  trailer  while  the  third  soldier,  using  the 
mission  planner  and  the  operational  orders,  locates  the  observation  sites  for  AMP  deployment.  Con¬ 
sideration  in  selecting  sites  must  include  field  of  view  for  the  sensors,  terrain  compatibility  for  land¬ 
ing,  and  near-line-of-sight  with  the  base  station  for  communications.  The  coordinates  of  the  selected 
sites  and  required  transit  waypoints  and  altitudes  would  then  be  down-loaded  to  the  platforms. 

After  checkout  at  the  launch  site,  each  AMP  will  autonomously  fly  to  its  designated  surveillance 
site.  When  the  platform  reaches  the  specified  landing  coordinates,  it  will  transmit  an  image  of  the 
terrain  at  the  site  for  the  operator  to  make  a  landing  decision.  Once  the  site  is  determined  to  be  suit¬ 
able,  the  operator  will  give  the  command  and  the  unit  then  lands  itself  Depending  on  terrain  type 
and  quality  of  the  information  available  to  the  operator,  the  platform  may  have  to  send  several 
images  as  it  descends.  The  high-level  supervisory  control  capabilities  and  three-dimensional  mobil¬ 
ity  allowed  by  the  VTOL  platform  are  ideally  suited  to  this  concept.  If  (during  landing)  there  is  loss 
of  communications  detected  on  the  platform  (due  possibly  to  intervening  terrain),  the  platform  will 
simply  elevate  until  communication  is  re-established  with  the  base  station,  and  then  the  platform  will 
be  directed  to  an  alternate  observation  location. 
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The  three  AMPs  will  be  deployed  sequentially  up  to  10  km  in  less  than  30  minutes  each.  Once 
landed,  the  platform  will  power  down,  and  the  sensor  suite  will  go  through  a  set-up  sequence  to  pro¬ 
vide  sensor  coverage  of  the  region  of  interest.  The  sensor  payload  will  consist  of  a  daylight  imaging 
camera,  a  forward-looking  infrared  (FLIR)  camera,  an  acoustic  sensor  unit  for  self  protection  and 
imager  cueing,  and  a  laser  rangefinder.  Sensor  processing  will  be  performed  on  the  platform  to 
detect  significant  motion  and/or  acoustic  signatures  before  alerting  the  operator.  The  portion  of  the 
image  containing  the  potential  target  will  be  sent  to  the  operator  and  displayed  within  the  corre¬ 
sponding  image  stored  in  the  operator’s  work  station.  The  operator  may  then  choose  to  get  a  range 
reading.  Each  AMP  can  be  repositioned  at  least  one  time  during  its  mission.  Upon  completion  of 
the  mission  the  operator  will  command  the  remote  platform  to  restart,  take  off,  rise  vertically  to  its 
transit  altitude,  and  return  to  the  base  station. 

Communication  between  the  AMPs  and  the  base  station  will  be  over  a  tactical-radio-based  data 
link.  The  control  and  communication  architecture  will  support  use  of  modular  mission  packages 
such  as  communications  relay,  barrier/minefield  detection,  and  nuclear/biological/chemical  agent 
detection. 
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3.  SYSTEM  DESCRIPTION 


The  AMGSSS  is  composed  of  two  physically  independent  portions:  the  air-mobile  portion  and  the 
ground-mobile  portion.  The  air-mobile  portion  consists  of  the  air-mobile  platform  and  the  mission 
payload  that  it  carries.  The  ground-mobile  portion  consists  of  an  HMMWV  on  which  a  control  dis¬ 
play  center  is  mounted,  and  a  trailer  that  carries  the  air-mobile  portion  before  deployment  for  surveil¬ 
lance.  This  section  describes  the  prototype  system  design  features. 

3.1  AIR-MOBILE  PLATFORM 

The  air-mobile  platform  (references  4,  5, 
and  6)  is  the  mobility  system  that  transports 
the  sensors  and  communications  payload 
from  one  operational  site  to  the  next.  The 
current  system  design  is  based  on  the 
Sikorsky  Cypher  vehicle  (a  ducted-fan, 

VTOL,  unmanned  aircraft)  with  a  sensor 
pod  mounted  on  top  (figure  3).  Projected 
weight  of  the  mission-ready  AMP  is 
270  lb,  including  the  60-lb  mission  payload 
and  fuel.  Sufficient  energy  will  be  avail¬ 
able  to  operate  the  sensors  in  surveillance 
mode  for  12  hours  and  to  restart  the  engine 
twice.  Weight  and  power  estimates  are 
based  on  commercially  available  hardware, 
modified  in  some  cases  for  the  AMGSSS 
application.  The  AMP  will  carry  sufficient 
fuel  for  a  30-km  transit  and  three  takeoffs  and 

3.1.1  Background 

The  following  sections  describe  details  of  the  Sikorsky  Cypher  vehicle,  which  is  the  current  AMP 
baseline. 

The  Cypher,  shown  in  figure  4,  is  based  on  a  combina¬ 
tion  of  proven  coaxial  rotor  technology  demonstrated  with 
the  Sikorsky  Advancing  Blade  Concept  (ABC)  aircraft  of 
the  1970s  and  shrouded  fantail  technology  demonstrated 
with  the  S-67  aircraft  and  S-76  LH  Fantail  Demonstrator 
aircraft.  The  Cypher  is  configured  with  two  counter-rotat¬ 
ing  four-bladed  rotors  shrouded  by  the  airframe.  The  air¬ 
frame  or  shroud  houses  propulsion,  avionics,  fuel,  payload, 
and  other  flight-related  hardware.  The  Cypher  concept  is 
an  innovative  approach  because  it  is  the  first  and  only 
ducted  configuration  that  uses  collective  and  cyclic  pitch 
on  the  rotor  blades  to  control  lift  and  moments  about  the 
three  body  axes.  The  result  of  this  approach  is  a  very 

maneuverable  platform  with  excellent  hover  efficiency.  Figure  4.  Cypher. 


Figure  3.  Air-Mobile  Platform  (AMP). 

landings. 
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3.1.2  Duct  Aerodynamics 

The  performance  characteristics  of  the  Cypher  are  a  function  of  both  the  rotor  and  the  shroud  trim 
states.  Performance  predictions  required  the  superposition  of  classical  duct  aerodynamics  with  the 
nonuniform  flow,  which  occurs  from  the  cyclic  blade  pitch  used  for  aircraft  trim.  As  a  ducted  device 
transitions  from  a  hover  state  into  forward  flight,  the  shroud  will  see  two  components  of  flow.  The 
simplest  is  flow  over  the  shroud  as  it  would  occur  without  the  presence  of  a  rotor.  This  flow  has  been 
tailored,  through  external  shroud  shaping,  to  produce  a  negative  (nose  down)  moment  to  partially 
offset  the  second  flow  component.  The  second  flow  component  is  the  induced  flow  through  the  duct, 
which  will  be  nonuniform  due  to  both  the  forward  flight  velocity  and  the  cyclic  blade  pitch.  The 
nose-up  pitching  moment  due  to  induced  flow  is  zero  in  hover,  increases  to  a  maximum  at  about  40 
knots,  and  then  diminishes.  The  rotor  cyclic  trim  requirements  thus  result  in  an  increase  in  power 
from  the  hover  condition  to  about  40  knots,  with  a  reduction  in  power  thereafter. 

3.1 .3  Physical  Characteristics 

The  physical  characteristics  of  the  Cypher  Technology  Demonstrator  (TD)  aircraft  are  presented  in 
table  1,  and  a  brief  description  of  major  subsystems  follows. 


Table  1 .  Cypher  physical  characteristics. 


Overall  Dimensions 

Rotor 

Fuselage  length  (ft) 

6.5 

Number  of  rotors 

2 

Fuselage  width  (ft) 

6.5 

Rotor  separation  (in) 

11.0 

Fuselage  height  (ft) 

2.0 

Rotor  radius  (ft) 

2.0  . 

Fuselage  cross  sectional  (in) 

19.5hx15w 

Tip  speed  (ft/s) 

650 

Blades  per  rotor 

4 

Volumes 

Structural  volume  (ft^) 

23.4 

Drive  System 

Fuel  tank  volume  (ft^) 

0.92 

Engine  RPM 

6500 

Sensor  payload  volume  (ft^) 

1.6 

Gearbox 

Spiral  Bevel 

Gear  reduction 

2.31:1 

Fuel  type 

Auto  Gas 

Weights 

Weight  empty  (lb.) 

170 

Normal  takeoff  weight  (lb) 

255 

Max.  gross  weight  (lb) 

300 

Usable  fuel  weight  (lb) 

40 

Sensor  payload  wt.  (max.  lb) 

45 

3.1.4  Rotor 

The  rotor  is  an  all-composite,  bearingless  system  designed  for  enhanced  reliability  and  maintain¬ 
ability  at  a  reduced  weight.  In  the  bearingless  rotor,  pitch  motions  of  the  blade  are  accomplished  by 
twisting  rectangular-shaped  beams.  The  beams  are  stiff  in  bending  but  torsionally  soft.  A  torsionally 
stiff  torque  tube  surrounds  the  flexbeams  and  transfers  control  motions  from  the  control  actuators  to 
the  outboard  end  of  the  flexbeam.  Six  actuators,  three  connected  to  each  rotor  swashplate,  are  incor¬ 
porated  for  independent  control  of  each  rotor.  By  using  a  coaxial,  counter-rotating  rotor  system,  no 
anti-torque  device  is  required,  and  differential  collective  can  be  used  for  directional  control. 
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3.1.5  Airframe 

The  Cypher  airframe  is  an  all-graphite  composite  reinforced  structure  that  consists  of  an  inner 
shroud,  outer  shroud  faring,  bulkheads,  support  struts,  and  center  mounting  stmcture.  The  inner 
shroud  wall  is  the  major  support  surface  for  mounting  the  engine.  The  support  struts  are  the  primary 
structure  and  provide  a  load  path  between  the  rotor  system  and  the  external  shroud.  Externally,  the 
airframe  is  shaped  to  be  aerodynamically  efficient  in  both  hover  and  forward  flight. 

3.1.6  Engine 

The  aircraft  is  powered  by  a  Norton  Motors  (now  known  as  UAV  Engines)  rotary  engine.  Model 
NR801T.  The  Norton  engine  has  a  high  power-to-weight  ratio  and  a  good  partial-power  fuel  con¬ 
sumption.  The  NR801T  is  a  combination  air-  and  liquid-cooled  engine  that  produces  45  hp  at  6,000 
rpm.  The  NR801T  used  incorporates  a  magneto-powered,  twin-spark-plug  ignition  system.  Engine 
operation  is  controlled  and  monitored  by  the  aircraft  flight-control  system. 

3.1.7  Transmission 

The  transmission  drive  system  consists  of  a  gearbox  and  drive  shaft  connected  to  the  rotary 
engine.  The  gearbox  has  a  spiral  bevel  gear  set  located  between  the  two  rotors.  Torque  is  transmitted 
through  the  drive  shaft,  to  the  pinion,  through  the  bevel  gears,  and  into  the  vertical  torque  shafts, 
thereby  turning  the  rotor  hubs  and  blades. 

3.1.8  Avionics 

The  avionics  architecture  is  based  on  the  philosophy  of  a  central  processor.  The  Vehicle  Mission 
Processor  (VMP),  the  brain  of  the  system,  integrates  airborne  sensors  and  controls  aircraft  flight, 
navigation,  vehicle  management,  payload,  and  communications.  For  the  demonstration  aircraft,  the 
Honeywell  Integrated  Flight  Management  Unit  (IFMU)  was  selected  for  the  VMP.  The  IFMU  com¬ 
prises  a  GG  1308  IFMU,  a  1750A  processor  module,  a  power  supply  module,  and  a  flexible  I/O 
module.  The  IFMU  uses  state-of-the-art  ring-laser  gyros  and  highly  accurate  accelerometers  for  iner¬ 
tial  measurements. 

The  VMP  receives  rates  and  accelerations  from  the  IMU,  and  through  strap-down  navigational 
software,  provides  the  flight-control  software  with  3-axis  linear  accelerations,  angular  rates,  linear 
velocities,  vehicle  attitudes,  and  vehicle  position.  The  strap-down  equations  are  updated  by  a  Global 
Positioning  System  (GPS)  via  a  Kalman  Filter  resident  in  the  VMP.  A  Radar  Altimeter  is  incorpo¬ 
rated  to  provide  accurate  altitude  and  assist  in  the  vertical  control  of  the  air  vehicle  during  automatic 
launch  and  recovery. 

All  software  in  the  VMP  is  written  in  Ada.  There  are  three  top-level  modules  hosting  mission 
management,  flight  controls,  and  strap-down  navigational  software.  The  mission  management  and 
flight-control  software  was  developed,  coded,  and  integrated  by  Sikorsky.  The  navigational  software 
was  an  integral  part  of  the  Honeywell  IFMU.  Software  integration  and  validation  was  conducted  on 
an  integrated  hot  bench  consisting  of  a  real-time  simulation  model  and  actual  flight  hardware. 

3.1.9  Flight  Controls 

One  of  the  major  objectives  of  the  Cypher  TD  program  is  to  demonstrate  a  user-friendly  VTOL 
aircraft  that  can  be  easily  controlled  with  simple  operator  commands.  For  this  reason,  the  flight- 
control  software  is  configured  to  receive  simple  inputs,  such  as  vehicle  heading,  altitude,  and  cruise 


7 


velocity.  The  aircraft  automatically  calculates  the  required  rotor  inputs  to  achieve  the  desired  flight 
conditions.  With  simplified  operational  commands,  the  operator  can  spend  more  time  with  payload 
operations  rather  than  with  piloting  the  aircraft.  Automatic  modes  such  as  heading  hold,  altitude 
hold,  velocity  hold,  position  hover  hold,  auto  takeoff,  and  auto  land  have  been  incorporated  to  sim¬ 
plify  vehicle  positioning  during  a  mission  or  operation  from  confined  areas. 

3.2  MISSION  PAYLOAD 

The  mission  payload  consists  of  the  sensor  suite,  onboard  controller,  communications,  and  battery 
power  pack.  The  AMP  serves  as  the  transport  platform  for  the  mission  package.  All  communication 
between  the  platform  and  the  control  station  passes  through  the  mission  payload. 

3.2.1  Sensor  Suite 

The  sensor  suite  comprises  two  subsystems:  the  landing  sensors  and  the  mission  sensors.  The 
landing  sensors  provide  information  to  the  operator  on  the  suitability  of  the  selected  landing  site  in 
terms  of  slope,  vegetation,  and  roughness.  The  present  approach  is  to  use  imagery  from  downward¬ 
pointing  cameras  that  is  transmitted  to  the  operator  for  landing  site  assessment.  Photogrammetric 
and  laser-scanning  techniques  are  potential  methods  for  slope  and  roughness  assessment. 

The  mission  sensor  payload  includes  a  daylight  video  camera,  a  forward-looking  infrared  (FLIR) 
camera,  a  laser  range  finder,  and  an  acoustic  sensor  for  queuing  to  target  presence  and  location.  The 
video  and  thermal  imagers  are  mounted  on  a  pan-and-tilt  unit  for  scanning  the  optical  sensors  over 
the  area  of  interest. 

3.2.2  Onboard  Controller 

The  onboard  controller  coordinates  communications,  image  processing,  sensor  control,  and  com¬ 
mands  to  the  vehicle  flight-management  unit.  Image  processing  is  handled  by  an  image-processing 
unit  within  the  controller.  Several  technologies  are  under  evaluation  for  image  processing  and  data 
compression. 

3.2.3  Communications 

The  communications  subsystem  transmits  commands  from  the  Control  Display  Center  (CDC)  to 
the  AMP  in  the  air  and  on  the  ground  at  its  remote  site.  The  subsystem  also  transmits  compressed 
surveillance  data  (including  FLIR  or  TV  images)  and  status  from  the  AMP  to  the  CDC.  Tactical 
radios  interoperable  with  Single  Channel  Ground  and  Airborne  Radio  System  (SINCGARS)  as  well 
as  high-speed,  line-of-sight,  radio  frequency  modems  have  been  used  for  communications.. 

3.2.4  Batteries 

Silver-zinc  battery  technology  has  been  selected  for  the  prototype  system  since  it  provides  high- 
energy  density,  is  readily  available,  and  has  known  characteristics.  This  is  not  the  technology  that 
would  be  used  in  an  operational  system.  The  secondary  battery  industry,  which  is  being  driven  by  the 
electric  transportation  and  portable  consumer  electronics  industries,  is  making  a  substantial  invest¬ 
ment  in  battery  technology.  We  closely  monitor  the  state  of  the  art  and  will  use  the  best  available 
technology  when  the  system  design  is  finalized.  Promising  technologies  include  nickel  metal 
hydride,  Uthium-ion,  and  zinc-air. 
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3.2.5  Payload  Weight  and  Power  Estimates 

Tables  2  and  3  provide  weight  and  power  estimates  for  the  payload  subsystems.  In  addition,  the 
total  energy  requirements  have  been  estimated  in  order  to  size  a  battery.  A  number  of  assumptions 
were  made  in  this  analysis. 

The  ground  mission  was  selected  as  12  hours.  This  allows  use  of  currently  available  silver-zinc 
batteries  with  a  reasonable  battery  weight.  Future  advances  in  battery  energy  density  would  provide 
extended  ground  surveillance  times. 

The  duty  cycle  for  the  video  camera  was  assumed  to  be  50  percent  and  for  the  FLIR  100  percent. 
The  FLIR  will  be  useful  at  night  and  in  the  daytime  for  classification.  To  provide  these  capabilities, 
the  FLIR  cooler  must  be  kept  on  at  all  times  (about  4  watts)  since  cool-down  time  is  10  minutes. 

The  acoustic  sensors  and  onboard  processor  were  given  a  100-percent  duty  cycle. 

The  communications  transmitter  was  assumed  to  be  on  10  percent  of  the  time.  This  would  imply  a 
smart  image  compression  system  that  only  sends  back  the  minimum  information  for  target  update 
data  due  to  the  low  bandwidth  available. 


Table  2.  AMGSSS  concept  payload  weight  and  power  estimate. 


Subsystem 

Weight  (lb) 

Power  (W) 

Source 

Video  1 

1 

3 

Cohu 

Zoom  lens  (incl.  motors) 

2 

1 

Canon 

FLIR 

3 

5 

Inframetrics 

FLIR  zoom  lens 

5  * 

0 

DIOP 

Acoustics 

2 

2 

Lockheed  Sanders 

Pan  &  tilt 

4 

1 

TRC 

Laser  rangefinder 

4 

5 

Melios 

Landing  video  camera 

0.5 

1 

Cohu 

Landing  near  IR  illuminator 

2 

100 

NVEC 

Communications  (VHF) 

5 

Racal  PRC -139 

(SINCGARS  interoperable) 

(incl.  antenna) 

Idle 

0.8 

Send 

50 

Receive 

10 

Onboard  processor 

15 

20 

Battery/power  conditioning 

17 

Yardney  Ag  Zn 

(60  W-hr/lb) 

Avg.**  Total 

60.5  lb 

64.5  W 

*  Zoom  is  a  lens  “switchout”;  requirement  for  this  needs  systems  analysis. 

**  ‘Typical”  duty  cycle  on  various  subsystems  gives  774  watt-hour  requirement  over  12-hour  mission 
time  on  ground. 
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Table  3.  System  battery  estimate. 


Subsystem 

Power 

(W) 

Duty  Cycle(*) 

%  of  12-hr  mission 

Energy  (12  hr) 
W-hr 

Video 

3 

50 

27  ** 

Zoom  lens  (incl.  mtrs) 

1 

10 

2  ** 

FLIR 

5 

100 

90  ** 

FUR  zoom  lens 

5 

1 

-|  ** 

Acoustics 

2 

100 

36  ** 

Pan  &  tilt 

Communications  (VHF) 

6.25 

100  Controller 

23  Motors 

112  ** 

Idle 

0.8 

80 

8 

Send  (Hi  Power) 

50 

10 

60 

Receive 

2.8 

10 

3 

Onboard  processor 

20 

100 

360  ** 

Engine  start  (3  starts) 

2000 

30  sec  ea. 

75  ** 

Total 

774  W-hr 

*  Duty  cycle  is  percent  “on  time”  during  typical  12-hr  mission. 

**  These  items  will  probably  require  “DC-DC  power  conversion,”  assumed  to  be  66.7-percent  efficient. 


The  engine  electrical  starter  requirements  assumed  three  starts  of  30-second  duration.  This  would 
accomplish  the  initial  deployment  to  a  remote  site,  deployment  to  an  alternate  location,  and  return 
home.  The  initial  start  may  be  by  an  electrical  umbilical. 

Finally,  the  visual,  acoustic,  and  onboard  processor  were  assumed  to  require  power  conditioning 
electronics.  Conservatively,  a  33-percent  power  loss  was  assumed  in  the  power  conversion.  The  com¬ 
munications  equipment  was  assumed  to  run  off  the  battery  directly. 

3.3  CONTROL  DISPLAY  CENTER  (CDC) 

The  operator  interface  is  based  on  workstation  and  graphical  user  interface  technology  and  will  be 
housed  in  a  HMMWV  equipment  shelter.  One  operator  will  control  and  monitor  the  three  AMPs. 

An  alert  will  be  given  when  images  or  sensor  information  requiring  evaluation  come  in  from  the 
platform.  The  operator  will  have  the  option  at  any  time  of  taking  control  of  the  sensors  on  any  AMP 
and  obtaining  images  of  the  surroundings.  The  CDC  will  also  house  a  GPS  unit  to  determine  its 
position  and  communications  equipment  for  connectivity  to  higher  echelons. 

The  CDC  will  include  an  automated  mission  planner  to  support  the  operator  in  selecting  the  land¬ 
ing  sites  for  the  AMPs.  Considerations  in  selecting  observation  sites  include  sensor  coverage  of  the 
mission  area,  terrain  suitability  for  landing,  and  communications  to  the  CDC.  The  mission  planner 
will  be  based  on  digital-terrain-database  technology  and  supporting  algorithms  to  aid  in  site  selec¬ 
tion. 
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4.  SYSTEM  STATUS 


Investigation  of  the  AMGSSS  concept  was  begun  in  FY  92.  Technical  summary  reports  were  pre¬ 
pared  at  the  end  of  FY  92  and  FY  93  (references  7  and  8).  Appendix  A  describes  how  the  program 
evolved  from  its  inception.  The  following  paragraphs  summarize  the  accomplishments  under  each 
major  subsystem  area. 

4.1  AIR-MOBILE  PLATFORM 

The  Air-Mohile  Platform  is  the  key  component  of  the  system.  Cypher  (figure  4)  a  ducted-fan, 
VTOL,  autonomous  flight,  remotely  controlled  takeoff  and  landing  vehicle  was  selected  as  the  flight 
platform  for  the  AMGSSS.  Cypher  was  developed  by  Sikorsky  primarily  with  corporate  funding. 
Development  and  testing  of  the  Cypher  over  the  past  2  years  has  demonstrated  the  following  capabil¬ 
ities: 

•  Fully  autonomous  takeoff  and  landing. 

•  Landing  on  slopes  to  13  degrees  with  indications  that  greater  slopes  were  possible. 

•  Supervised  autonomous  flight  control  and  navigation,  including  hover  hold,  position  hold,  alti¬ 
tude  hold,  velocity  hold,  and  “return  home.” 

Under  contract  to  NRaD,  Sikorsky  conducted  a  design  concept  study  (reference  5).  Appendix  B  is 
abstracted  from  reference  5  and  provides  vehicle  design  concepts  for  the  AMGSSS  mission  as  envi¬ 
sioned  at  that  time.  Subsequently,  some  concepts  have  been  modified. 

4.2  MISSION  PAYLOAD  PROTOTYPE  INCLUDING  CONTROL  STATION 

In  FY  95,  program  funding  prevented  NRaD  from  proceeding  with  the  updated  plan  for  full  sys¬ 
tem  development  (reference  9).  Instead,  NRaD  undertook  the  development  of  an  AMGSSS  Mission 
Payload  Prototype  (MPP).  The  MPP  consists  of  two  units  analogous  to  the  two  components  of  the 
AMGSSS,  i.e.,  the  AMP  payload  (remote  unit)  and  the  CDC.  The  MPP  remote  unit,  shown  in  fig¬ 
ure  5,  comprises  the  video  camera,  FLIR,  laser  range  finder,  subsystem  controller/payload  processor 
(PP),  pan-and-tilt  unit,  and  the  payload  portion  of  the  communications  subsystems  proposed  for  the 
AMGSSS  prototype.  The  Control  Display  Center  (figure  6)  contains  the  base  station  portion  of  the 
communications  subsystem  and  a  laptop  computer  operator  interface.  Figure  7  is  a  block  diagram  of 
the  MPP. 

The  objective  of  the  MPP  is  to  explore  the  integration  issues  of  the  payload,  communications,  and 
operator  interface.  The  MPP  also  provides  a  platform  on  which  to  test  various  data  compression, 
image  processing,  and  target-detection  hardware  and  software.  The  MPP  allows  early  interaction 
with  the  user  community  on  how  users  would  use  the  information  available  from  the  remote  plat¬ 
forms  and  evaluation  of  operator  interface  and  communications  issues.  The  MPP  has  been  bread- 
boarded  and  run  through  preliminary  debugging  and  demonstration  trials.  Both  the  Racal  PRC-139 
and  SINCGARS  tactical-band  radios  are  being  used  for  communications,  as  well  as  radio  frequency 
Ethernet  modems. 
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Figure  5.  MPP  remote  unit. 


Figure  6.  MPP  control  display  center. 


- ►  Ethernet  TCP/IP  connections  (from  client  to  host) 

■■■■■►  TCP/IP  connections  when  radio  modems  are  off 
< — >  Other  digital  connections 

Figure  7.  AMGSSS  MPP  system. 


4.2.1  Communications 


A  PC-card  version  of  the  Tactical  Communications  Interface  Module  (TCIM)  is  used  to  interface 
the  computers  with  the  radios.  The  data  throughput  with  error  correction  and  standard  military  proto 
cols  is  on  the  order  of  4000  to  8000  bits  per  second. 


As  an  initial  evaluation  of  the  non-line-of-sight  communications  performance,  the  remote  portion 
of  the  MPP  breadboard  was  mounted  in  a  HMMWV.  Images  were  collected  and  transmitted  from 
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the  HMMWV  as  it  was  driven  around  the  NRaD  facility  on  Point  Loma,  San  Diego.  SINCGARS 
radios  were  used  as  the  small  PRC  units  had  not  yet  been  received.  Images  from  the  moving  vehicle 
on  one  side  of  Point  Loma  were  received  reliably  at  NRaD’s  Bayside  faciUty  on  the  opposite  side. 
256-by-256  pixel  images  were  transmitted  at  a  rate  of  3  frames  per  minute  with  the  4-kilobit  data 
rate. 

Appendix  C  presents  additional  information  on  radio  selection. 

4.2.2  Sensors 

Sensors  for  the  MPP  are  those  that  are  proposed  for  the  AMGSSS  prototype.  The  selection  was 
based  mainly  on  performance,  weight,  and  power  consumption.  The  FLIR  is  the  Inframetrics  Infra¬ 
cam.  After  3  days  and  1  night  of  testing  at  Camp  Pendleton,  CA,  the  Infracam  with  a  100-mm  lens 
showed  its  sensitivity  to  be  adequate  to  discern  moving  targets  at  up  to  5  km.  A  Cohu  2122  black  and 
white  video  camera  with  Canon  J 10X10  (10  to  100  mm)  zoom  lens  with  a  2X  range  extender  was 
selected  for  daytime  imagery.  We  intend  to  use  the  Contraves  laser  range  finder  that  is  based  on 
erbium-glass  technology  and  weighs  0.6  kg,  but  selected  the  Riegl  Lasertape  as  a  short  range  (1  km), 
low-cost,  interim  solution  for  the  prototype. 

It  was  difficult  to  find  an  off-the-shelf  pan/tilt  that  could  meet  weight,  payload,  speed,  and  posi¬ 
tion-feedback  requirements.  The  closest  to  meeting  such  requirements  was  the  TRC  Zebra  unit, 
which  has  a  limited  weight  capacity.  The  motor  design  was  analyzed,  found  adequate,  and  then 
tested  with  a  pair  of  5-lb  weights  mounted  to  simulate  the  anticipated  rotational  inertia.  Performance 
was  adequate  if  speeds  were  kept  to  less  than  100  degrees  per  second. 

Three  acoustic  detection  systems  have  been  qualitatively  evaluated  in  the  field.  The  systems 
showed  promise,  but  none  met  all  of  our  criteria. 

Appendix  D  provides  additional  information  on  the  selection  of  sensors  for  the  MPP. 

4.2.3  Image  Processor 

The  MPP  image  processor  (IP)  performs  the  image  processing,  including  source  (FLIR/TV)  selec¬ 
tion,  frame  grabbing,  image  contrast  enhancement,  video  motion  detection,  and  image/video  com¬ 
pression.  The  IP  will  serve  as  a  testbed  for  applications  related  to  remote  day/night  video  surveil¬ 
lance  using  small  low-power,  embedded-image-processing  hardware. 

Three  variations  of  the  IP  hardware  were  evaluated:  (1)  an  X86  central  processor  unit  (CPU)  and 
frame  grabber,  (2)  an  X86  CPU  and  digital  signal  processor  (DSP)  frame  grabber,  and  (3)  an  X86 
CPU  and  application-specific  integrated  circuit  (ASIC)  vision  processor.  The  image-processing 
algorithms  are  hosted  differently  among  these  three  configurations.  Configurations  (1)  and  (2)  are 
PC/104-based,  while  (3)  is  ISA-based.  Configuration  (3)  provides  the  highest  performance  capabil¬ 
ity.  As  an  embeddable  image-processing  testbed,  the  IP  will  be  used  to  investigate  and  develop 
robust  algorithms  for  remote  video  surveillance  applications.  These  algorithms  include  error  resil¬ 
ient  image/video  compression  for  transmission  over  noisy  radio  channels;  camera  image  stabilization 
for  image  jitter  induced  by  wind;  better  compression  techniques  for  low-bandwidth  channels  and 
directed  motion  detection  for  low  signal-to-noise  video  sequences. 

Appendix  E  provides  additional  information  on  image  processing  for  the  MPP  and  AMGSSS. 
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4.2.4  Onboard  Controller 

The  AMGSSS  MPP  Remote  Platform’s  onboard  controller,  with  the  Payload  Processor  (PP)  as  its 
core,  implements  a  well-defined  “server”  functionality,  executing  commands  it  receives  from  the 
CDC,  and  (especially  for  debugging  purposes)  from  other  clients,  including  the  PP’s  own  Command 
Line  Interface  (CLI).  Mechanisms  implemented  on  the  PP  support  debugging  as  well  as  operational 
requirements,  and  have  been  designed  to  easily  accommodate  the  integration  of  additional  or 
enhanced  sensor  subsystem  components.  The  PP  communicates  via  RS-232  links  with  microcontrol¬ 
lers  embedded  within  several  commercial  off-the-shelf  (COTS)  subsystems:  pan/tilt  unit,  FLIR,  laser 
rangefinder,  and  acoustic  detection  system.  These  microcontrollers  maintain  internal  state  informa¬ 
tion  that  should  be  “mirrored”  by  the  subsystem  state  information  held  by  the  PP  itself. 

Appendix  F  describes  the  onboard  controller  for  the  MPP  in  greater  detail. 

4.2.5  Control  Display  Center 

A  portable  operator  Control  Display  Center,  shown  in  figure  6,  has  been  developed  for  the  MPP 
using  software  running  under  the  Windows  operating  system.  The  use  of  network  communications 
allows  the  program  to  control  the  remote  sensor  package  and  display  the  remote  sensor  status  as  well 
as  images  transmitted  in  real  time.  Special  attention  was  given  to  creating  an  operator  interface  that  is 
simple  and  intuitive  to  use.  The  operator  is  able  to  point  and  click  with  a  mouse  to  do  most  opera¬ 
tions  necessary  to  control  the  remote  unit. 

Appendix  G  describes  the  Control  Display  Center  for  the  MPP  in  detail. 
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5.  CONCLUSIONS  AND  RECOMMENDATIONS 


5.1  OVERALL 

As  concluded  in  the  U.S.  Army  Missile  Command  (MICOM)  report  (reference  10),  PSEMO  and 
NRaD  have  made  good  use  of  minimal  funding  for  conceptual  studies,  research,  and  development  on 
the  AMGSSS.  Since  the  MICOM  report  (reference  10)  was  prepared,  additional  flight  tests  of  the 
platform  and  field  tests  of  a  prototype  payload  and  portable  control  display  center  have  demonstrated 
the  technical  feasibility  of  the  AMGSSS  concept. 

At  the  overall  system  level,  one  of  the  next  important  steps  would  be  the  integration  of  the  payload 
with  the  flight  platform.  Conclusions  and  recommendations  regarding  the  various  subsystems  that 
compose  the  AMGSSS  are  presented  in  the  following  sections. 

Inadequate  funding  prevented  the  program  from  reaching  its  goal  of  developing  and  testing  a  com¬ 
plete  operating  demonstration  model  of  the  system  in  4  years.  It  is  recommended  that  the  program 
be  continued  as  an  Advanced  Technology  Demonstration  or  Advanced  Concept  Technology  Devel¬ 
opment  project. 

5.2  AIR-MOBILE  PLATFORM 

Further  development  and  testing  of  the  air-mobile  platform  is  required  to: 

•  combine  an  increase  engine  power  with  a  reduction  in  weight  in  order  to  increase  the  flight 
speed  and  environmental/operational  envelope 

•  reduce  the  engine-noise  signature  further 

•  reduce  platform  complexity  and  cost 

•  provide  for  supervised  landing  at  remote  unprepared  sites  (including  landing  site  evaluation) 

•  demonstrate  stable  flight  in  AMGSSS  configuration,  i.e.,  with  simulated  sensor  pod  mounted 

•  incorporate  remote  engine  start 

•  provide  for  heavy-fuel  utilization 

5.3  SENSOR  SUITE 

5.3.1  Visual  Imaging 

The  Cohu  2122-1024  camera  with  the  Canon  JIOXIOREA-IAII  zoom  lens  and  a  2X  range 
extender  met  all  AMGSSS  requirements  for  daylight  video. 

5.3.2  Thermal  Imaging 

The  Inframetrics  InfraCam  was  selected,  with  a  100-mm  lens.  This  imager  uses  a  platinum  silicide 
focal-plane  array  for  high  uniformity  and  a  proprietary  Stirling  cycle  dewar  cooler  to  combine  light 
weight  with  low  power  and  reasonably  high  image  quality.  The  lens  is  a  compromise  to  combine 
availability,  long  range,  light  weight,  and  low  cost  while  not  narrowing  the  view  too  much  for  pan¬ 
orama  gathering.  A  dual-field-of-view  lens  would  be  preferable  but  would  add  significantly  to  the 
cost  and  5  lb  or  more  to  the  weight. 
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5.3.3  Laser  Ranging 

A  Contraves  laser  rangefinder  is  recommended  if  the  high  cost  is  not  prohibitive  (or  the  price  has 
dropped)  and  units  are  available.  Alternatives  include  the  Reigl  Lasertape,  if  shorter  ranges  are  suffi¬ 
cient,  or  the  Melios  if  long  range  is  required.  Since  the  market  is  rapidly  evolving,  vendors  should 
be  contacted  again  at  the  time  of  procurement  and  new  developments  evaluated. 

5.3.4  Azimuth-Elevation  Mount 

The  Transitions  Research  Corporation’s  (TRC)  Zebra  model  with  NRaD  modifications  meets  the 
needs  of  AMGSSS  and  is  recommended. 

5.3.5  Acoustic  Sensor 

Final  selection  of  an  acoustic  sensor  will  depend  on  the  AMGSSS  vehicle.  Until  then,  flexibility 
can  be  maintained  through  incorporation  of  an  extra  RS232  serial  interface  for  communication  with 
any  acoustic  sensor  system.  Several  candidates  are  available,  but  none  has  been  selected  at  this  time. 

5.3.6  Market  Surveys 

New  market  surveys  will  be  performed  if  the  program  moves  ahead  to  take  advantage  of  improved 
technology  and  higher  performance  sensors. 

5.4  IMAGE  CAPTURE  AND  PROCESSING 

The  AMGSSS  image-processing  tasks  have  to  be  combined  into  an  integrated  image  processing 
subsystem.  This  is  the  only  approach  that  will  satisfy  the  very  restrictive  requirements  for  power, 
weight,  and  cost  without  sacrificing  subsystem  performance.  An  integrated  image-processing  sub¬ 
system  is  one  that  incorporates  compression,  video  motion  detection,  terrain  slope  determination,  and 
various  image-enhancement  features.  Any  image-processing  hardware  solution  should  take  advan¬ 
tage  of  recent  developments  in  low  power,  programmable  multiprocessor  vision  ASICs. 

Image-preprocessing  tasks  should  not  be  underestimated  for  tactical  surveillance  applications  like 
AMGSSS.  These  tasks,  including  image  stabilization,  contrast  enhancement,  noise  filtering,  edge 
enhancement,  and  sensor  fusion,  play  a  vital  role  in  providing  the  essential  surveillance  imagery  data 
to  the  operator  over  low-bandwidth  LPI/LPD  tactical  radio  links. 

We  recommend  funding  two  parallel  approaches  for  developing  an  integrated  image  processor  for 
AMGSSS:  a  downsized  version  of  David  Samoff  Research  Center’s  VFE-100  and  the  Delta 
Information  System’s  Vidicoder  vision  processor  board. 

5.5  ONBOARD  CONTROLLER 

Recommendations  for  future  development  of  the  onboard  controller  follow. 

5.5.1  Enhanced  Robustness  for  Subsystem  Control 

Error  conditions  or  other  events  of  interest  internal  to  the  subsystems  may  not  be  adequately 
reported  to  or  detected  by  the  Payload  Processor  (PP).  The  PP  should  be  enhanced  to  deal  with  these 
situations  more  robustly.  Specifically: 


•  The  low-level  C  code  controlling  the  pan/tilt  unit  should  be  reviewed  and  revised. 

•  Additional  error  checks  should  be  inserted  into  the  low-level  code  interfacing  the  FLIR  with 
the  laser  rangefinder. 

•  Opportunities  for  inserting  LONWorks  technology  into  the  onboard  controller  should  be  reas¬ 
sessed. 

5.5.2  Enhancement  of  Message  Addressing 

The  message-addressing  scheme  used  in  AMGSSS  should  be  refined  to  incorporate  process  ID 
within  the  platform  or  CDC  as  well  as  platform  ED.  The  refinement  should  support  flexible  opera¬ 
tion  and  debugging  activities  in  an  environment  including  both  multiple  AMGSSS  vehicles  and  mul¬ 
tiple  CDCs. 

It  should  be  kept  in  mind,  however,  that  the  most  critical  current  deficiencies  in  the  AMGSSS 
MPP  systems  involve  the  tactical  radio  link  and  its  controller,  not  the  onboard  controller.  Moreover, 
once  the  radio  link’s  performance  has  been  optimized,  it  is  almost  certain  that  the  details  of  the 
CDC’s  operator  interface  will  become  the  focus. 

5.6  COMMUNICATIONS 

The  fundamental  question  concerning  the  design  of  the  AMGSSS  communications  subsystem  is, 
“What  frequency  band  should  be  used?”  The  selection  was  narrowed  to  two  choices:  the  VHP  tacti¬ 
cal  band  or  the  commercial  UHF  band  and  their  associated  equipment.  The  advantages  and  disad¬ 
vantages  of  each  approach  are  discussed  in  detail  in  Appendix  C. 

Although  the  tactical  band  radios  have  the  potential  for  beyond-line-of-site  transmission,  in  real 
scenarios,  performance  is  erratic  and  difficult  to  predict.  Although  standard  tactical  equipment  may 
be  used,  special  software  is  required,  the  radios  must  be  shielded  from  radiation  from  the  computers, 
and  the  data  rate  is  low. 

The  commercial  UHF  band  and  equipment  provide  high  data  rates,  data  security,  readily  available 
small  and  lightweight  hardware,  and  program  control  of  hardware  and  software.  However,  repeaters 
would  be  essential,  little  standard  military  equipment  could  be  used,  and  frequency  allocation  con¬ 
flicts  are  possible. 

In  1994,  the  tactical  radio  approach  seemed  to  have  the  most  merit:  The  capability  of  maintaining 
a  radio  link  without  maintaining  line  of  sight  was  considered  to  be  of  paramount  importance;  the 
standardization  of  SINCGARS  was  very  attractive;  and  the  usage  of  existing  military  communication 
protocols  was  very  practical.  In  practice,  a  predictable  radio  link  was  found  to  be  more  valuable  than 
a  versatile  one;  the  lightweight  SINCGARS  substitute  was  not  a  strong  performer;  and  the  existing 
protocols  were  found  to  be  inappropriate  for  our  application. 

The  tactical  radio  system  could  be  improved  by  adding  another  radio  to  create  full-duplex  commu¬ 
nications,  using  the  new  dual-channel  PC  Card  TCIM  from  Magnavox,  fixing  the  shielding  problem 
with  the  Racal  radios,  changing  our  communications’  architecture  to  one  that  can  reliably  handle 
data  errors,  and  completely  changing  the  radio  control  software.  If  these  changes  were  made,  the 
data  rate  would  increase  to  6000  to  8000  bits  per  second,  no  link  initialization  would  be  needed,  and 
the  latency  would  decrease  by  an  order  of  magnitude.  However,  the  actual  effects  of  real  hills  would 
still  be  somewhat  unpredictable,  and  the  data  rate  would  still  be  a  fraction  of  our  true  requirements. 
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Therefore,  a  change  to  a  wireless  (UHF)  LAN  should  be  seriously  considered.  This  approach 
would  require  a  repeater  in  most  circumstances.  Use  of  a  repeater  does  create  some  practical  disad¬ 
vantages.  However,  the  virtues  of  a  predictable  link,  straightforward  software,  and  a  high  data  rate 
seem  to  be  more  important  factors  when  the  system  is  actually  used.  For  in-flight  operation,  a  VHF 
backup  receiver  should  be  used,  but  this  would  not  add  significantly  to  the  overall  weight  of  the  pay- 
load. 

A  market  survey  is  recommended  to  determine  the  best  candidates  for  wireless  LAN  transceivers. 
Then,  those  candidates  should  be  tested  to  reveal  unforeseen  problems.  If  the  wireless  LAN  per¬ 
forms  well  in  the  field,  we  suggest  that  these  units  replace  the  current  tactical  radio  system.  How¬ 
ever,  it  may  be  desirable  to  retain  the  current  tactical  radio  system  hardware  for  in-flight  backup 
communications . 

5.7  BATTERIES 

Further  evaluation  of  battery  technologies  needs  to  be  conducted  to  verify  or  revise  estimates  of 
their  ability  to  provide  the  power  needed  by  the  AMGSSS  for  powering  the  system  and  restarting  the 
platform  engine  at  remote  sites. 

5.8  CONTROL  DISPLAY  CENTER 

The  Control  Display  Center  has  been  developed  to  meet  the  immediate  needs  of  the  AMGSSS 
Mission  Payload  Prototype.  In  order  to  expand  the  system  to  the  original  AMGSSS  system  objec¬ 
tives  (references  11,  12,  13,  and  14  ),  various  changes  will  be  needed  including: 

Conversion  to  a  32-bit  operating  system  such  as  Windows-NT.  The  power  of  a  32-bit  operating 
system  will  be  needed  to  address  the  following  five  issues: 

1.  Incorporating  three-dimensional  maps,  such  as  DMA-supplied  DTED  (elevation  data)  and 
ADRG  (raster)  maps.  A  combination  of  maps  such  as  the  two  mentioned  will  be  neces¬ 
sary  to  generate  a  3-D  map  of  the  environment  to  enhance  operator  awareness  and  allow 
mission  planning  on  the  Control  Display  Center. 

2.  Adding  mission  planning  capabilities.  This  includes  programming  and  supervision  of  the 
flight  and  landing  of  the  air-mobile  platforms. 

3.  Expanding  support  to  three  air-mobile  platforms/sensor  suites. 

4.  Addition  of  the  video-streaming  capability. 

5.  Enhancing  the  user  interface  based  on  feedback  from  operators  during  field  tests. 
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APPENDIX  A:  PROGRAM  EVOLUTION 


The  technical  development  plan  for  the  AMGSSS  (reference  A-1)  called  for  three  development 
phases  plus  two  test  phases  leading  to  the  Milestone  n  decision.  Figure  A-1  shows  timelines  for  the 
work  actually  conducted  through  FY  95.  Figure  A-2  illustrates  the  plan,  as  of  the  end  of  FY  94,  for 
taking  the  system  to  Milestone  EL. 

In  Phase  I,  technologies  applicable  to  the  system  were  surveyed,  and  a  system  concept  was  formu¬ 
lated.  The  early  portions  of  Phase  II  involved  further  subsystem  technology  evaluations  including 
tests  and  demonstrations  of  the  flight  platform.  In  Phase  H,  the  platform  contractor  was  to  further 
develop  an  existing  platform  and  apply  lessons  learned  to  the  design  and  fabrication  of  a  new  air-mo- 
bile  platform.  In  parallel,  NRaD  was  to  acquire/develop  the  prototype  payload  subsystems  and  a 
Control  Display  Center  for  operation  of  the  system.  The  payload  equipment  would  be  given  to  the 
platform  contractor  for  integration  with  the  flight  platform.  The  platform  would  then  be  integrated 
with  the  control  display  system,  and  the  entire  prototype  system  would  be  extensively  tested. 

Phase  in  would  follow  the  same  general  course  as  Phase  n,  but  three  flight  platforms  with  their 
payloads  would  be  assembled  and  integrated  with  a  new  Control  Display  Center.  After  Phase  HI 
testing,  the  system  would  go  into  Technical  Feasibility  Testing  and  then  Early  User  Evaluations. 

CONCEPT  FEASIBILITY:  JULY-OCT  1992,  PHASE  I 

In  the  last  quarter  of  FY  92,  NRaD  performed  an  AMGSSS  concept  feasibility  study  by  assessing 
the  availability  and  maturity  of  the  required  subsystem  technologies  and  developing  preliminary 
power  and  weight  budgets  for  the  air-mobile  platform  (AMP)  (reference  A-2,  p.  21).  This  work  indi¬ 
cated  that  the  concept  was  feasible;  that  is,  there  were  technologies  available  that  had  demonstrated 
the  general  function  and  level  of  performance  required.  The  investigation  also  supported  the  prepa¬ 
ration  of  a  program  plan  that  included  the  schedule  and  cost  for  a  system  demonstration. 

MARKET  SURVEY:  FY  1993,  PHASE  I  (CONTINUED) 

In  FY  93,  the  Physical  Security  Equipment  Management  Office  (PSEMO),  Ft.  Belvoir,  VA.,  tasked 
NRaD  to  perform  a  market  survey  (availability  of  products  for  use  in  AMGSSS),  develop  draft  eval¬ 
uation  criteria,  and  perform  Trade-Off  Determination  and  Best  Technical  Approach  analyses,  where 
possible,  to  support  preparation  of  the  Concept  Formulation  Package  by  the  Program  Office.  The 
AMGSSS  was  divided  into  subsystems.  For  each  subsystem,  functional  requirements  were  deter¬ 
mined.  Then  technology  surveys  were  conducted.  Literature  was  searched  and  contacts  made  with 
companies,  academic  institutions,  and  individuals  with  expertise  in  the  relevant  technical  areas.  For 
each  subsystem,  alternatives  were  formulated  for  performing  the  functional  requirements,  trade-off 
analyses  conducted,  options  evaluated,  and  the  best  technical  approach  selected.  In  several  subsys¬ 
tem  areas,  final  decisions  had  to  await  field  evaluations  in  AMGSSS-specific  situations  or  finaliza¬ 
tion  of  the  operational  requirement.  A  detailed  report  of  the  investigations  was  published  (refer¬ 
ence  2). 

The  market  surveys  had  not  indicated  an  abundance  of  demonstrated,  mature  air  vehicles  suited  for 
the  role  of  the  AMGSSS  air-mobile  platform.  Therefore,  it  was  decided  to  canvass  industry  to  deter¬ 
mine  if  this  capability  could  be  demonstrated,  and  in  April  1993,  a  Broad  Agency  Announcement 
(BAA)  was  published  soliciting  proposals  for  AMGSSS  platforms.  The  announcement  outlined  a 
three-phase  program.  In  Phase  I,  vertical  takeoff  and  landing  and  transition  to  horizontal  flight 
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would  be  demonstrated  with  an  existing  platform.  The  contractors  would  also  develop  preliminary 
concepts  showing  how  their  platform  could  be  modified  to  support  the  AMGSSS  concept  to  deploy 
up  to  three  vehicles  to  remote  sites.  In  Phase  11,  the  most  promising  of  the  approaches  would  be 
selected  for  evaluation  against  AMGSSS-specific  requirements.  These  included  remote  takeoff  and 
landing,  landing  on  slopes,  autonomous  flight,  payload  capacity,  limited  flight  quality  testing,  and 
development  of  an  AMGSSS-specific  platform  design.  In  Phase  HI,  the  contractor  would  integrate 
the  payload  packages  with  the  platform  and  deliver  three  such  platforms  to  the  government  for 
integration  and  evaluations  with  the  Control  Display  Center.  The  BAA  restricted  the  competition  to 
vertical  takeoff  and  landing  craft  using  shrouded-propeller  (or  ducted-fan)  designs. 

Six  proposals  were  received  and  three  contracts  were  awarded  for  Phase  I.  The  contracts  were  to 
Sikorsky  for  its  Cypher,  McDonnell  Douglas  for  the  DASS,  and  a  team  of  Stratos  and  Moller  for  a 
version  of  the  Moller  Aerobot  platform.  McDonnell  Douglas  was  awarded  a  Phase  I  contract  even 
though  its  only  vehicle  had  been  destroyed  in  a  crash.  This  award  was  made  on  the  basis  that  the 
technology  had  been  recently  demonstrated,  the  design  was  simple  and  potentially  low  cost,  and 
because  the  company  indicated  a  willingness  to  construct  a  new  vehicle  for  Phase  II  using  internal 
company  funds. 

As  of  the  end  of  FY  93,  the  Cypher  Phase  I  flight  demonstration  had  been  completed.  Although  a 
videotape  of  a  DASS  flight  was  accepted  as  proof  of  the  design  capability  of  the  DASS,  McDonnell 
Douglas  decided  not  to  complete  the  Phase  I  tasking  since  it  did  not  have  an  existing  vehicle  and  was 
unwilling  to  build  a  new  craft  with  company  funds.  The  Stratos-Moller  team  Aerobot  platform  was 
demonstrated  early  in  FY  94. 

The  Phase  I  demonstration  flights  indicated  suitable  technology  existed  on  which  to  base  an 
AMGSSS  air  platform  design.  The  Sikorsky  Cypher  platform  appeared  to  be  the  most  advanced  and 
came  closest  to  being  able  to  carry  the  necessary  payload.  However,  it  was  apparent  that  further 
development  would  be  required. 

The  remote  operation  concept  studies  of  Phase  I  provided  some  assurance  that  air  platform  design 
modifications  were  feasible  that  would  allow  incorporation  of  the  AMGSSS  payload  and  remote 
landing,  and  takeoff  as  well  as  remote  engine  start. 

As  a  result  of  the  FY  93  investigations,  the  system  concept  and  program  plan  were  updated. 

SUBSYSTEMS  DEVELOPMENTS:  FY  1994,  PHASE  II 

During  this  year,  studies,  experiments,  and  designs  were  undertaken  to  finalize  the  AMGSSS  sub¬ 
system  approaches. 

Air-Mobile  Platform  (See  Appendix  B  for  details.) 

The  original  plan  as  outlined  in  the  BAA  announcement  was  to  select  two  contractors  for  Phase  n 
flight  demonstrations  and  design  work.  However,  reduced  funding  limited  the  selection  to  one  con¬ 
tractor.  Sikorsky  was  selected  as  the  sole  Phase  n  contractor  since  its  Cypher  vehicle  was  considered 
the  most  advanced  and  came  closest  to  meeting  the  payload  requirements  of  the  AMGSSS  mission. 
Limited  FY  94  funding  also  did  not  permit  acquisition  or  development  of  the  payload  subsystems  as 
described  in  the  program  plan. 
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As  a  result  of  briefings  by  PSEMO  within  the  Army,  the  Dismounted  Battlespace  Battle  Labora¬ 
tory,  Ft.  Benning  requested  a  flight  demonstration  of  the  Cypher  at  the  Commanders’  Conference  at 
Ft.  Benning  in  May  1994.  Therefore,  that  demonstration  was  included  in  the  Phase  n  contract  with 
Sikorsky.  The  demonstration  was  successfully  completed  leading  to  program  support  including  the 
entry  into  the  Army  review  and  comment  cycle  of  a  draft  Mission  Needs  Statement  (MNS),  prepared 
by  the  Dismounted  Battlespace  Battle  Laboratory.  The  demonstration  at  Ft.  Benning  was  also  very 
useful  in  providing  information  concerning  the  Army’s  operating  environment  as  well  as  user  feed¬ 
back  on  the  AMGSSS  design  concepts. 

Following  the  Commanders’  Conference,  Sikorsky’s  Phase  11  flight  testing  demonstrated  advanced 
technical  capabilities  pertinent  to  the  AMGSSS  mission  including  the  ability  of  the  vehicle  to  land  on 
and  take  off  from  sloped  surfaces  and  to  perform  closed  loop,  controlled,  hands-off  takeoffs  and 
landings. 

Payload 

Candidate  sensors  and  communications  equipment  were  evaluated  in  field  experiments.  Reeord- 
ings  were  made  of  the  video  and  infrared  sensor  output  in  a  variety  of  scenes  with  and  without  tar¬ 
gets.  These  were  to  be  distributed  to  vendors  to  determine  the  capability  of  various  sources  to  adapt 
their  existing  image-compression  and  target-motion-detection  techniques  to  the  AMGSSS  mission. 

Control  Display  Center 

The  systems  control  and  display  requirements  were  determined,  and  progress  was  made  in  devel¬ 
oping  control-display  system  concepts. 

Technical  Development  Plan 

As  a  result  of  the  FY  94  investigations,  the  system  concept  was  updated,  and  a  technical  develop¬ 
ment  plan  was  formulated.  The  development  program  would  bring  the  AMGSSS  to  a  Milestone  n 
decision  point  in  4  years. 

MISSION  PAYLOAD  PROTOTYPE  WITH  CONTROL  STATIOI^:  FY  1995,  PHASE  II 
(CONTINUED) 

Limited  FY  95  funding  did  not  allow  implementation  of  the  plan.  Instead,  FY  95  efforts  were 
focused  on  prototyping  the  mission  payload,  communications,  and  operator  interface  subsystems, 
which  together  were  termed  the  Mission  Payload  Prototype  (MPP).  The  MPP  would  provide  valu¬ 
able  information  on  payload  weight  and  performance  and  communications  performance.  Also,  it 
would  allow  early  input  from  the  operators  on  the  information  the  system  provided. 

Sikorsky  was  tasked  to  fly  the  Cypher  vehicle  with  a  mockup  of  an  elevated  sensor  pod  to  evaluate 
the  effect  on  aerodynamics  of  flight  with  a  simulated  AMGSSS  payload  package.  Sikorsky  also 
made  progress  in  engine  quieting. 
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APPENDIX  B:  DESIGN  CONCEPT  FOR  AMGSSS 
AIR-MOBILE  PLATFORM 


(The  following  is  taken  from  the  Sikorsky  AMGSSS  Phase  1  final  report.  A  number  of  these  design 
concepts  have  been  modified  since  that  report  was  written.) 

The  AMGSSS  air-mobile  platform  (AMP)  is  based  on  a  modified  Cypher  unmanned  vehicle.  The 
Cypheraircraft  is  configured  with  two  counter-rotating  rotors  shrouded  by  a  fuselage  that  houses  the 
aircraft’s  subsystems.  The  counter-rotating  rotors  counteract  the  gyroscopic  forces  and  slip-stream 
rotation  associated  with  single  rotor  and  ducted  fan  configurations.  The  rotors  incorporate  cyclic  and 
collective  blade  pitch  controls  to  control  vehicle  motion.  The  toroidal  shape  of  the  fuselage  is  opti¬ 
mized  to  provide  lift  in  hover  and  stability  in  forward  flight.  To  enhance  AMGSSS  capabilities  the 
mission  sensors  are  housed  in  an  elevated  pod.  The  five  major  systems  of  the  air  vehicle  are 
described  below. 

AIRFRAME  ARRANGEMENT/STRUCTURE 

The  Cypher  airframe  is  an  all  graphite  composite  reinforced  structure  consisting  of  the  inner 
shroud  ring,  an  outer  shroud  fairing,  bulkheads,  and  support  struts.  The  AMGSSS  configuration  adds 
to  this  airframe  a  spring  landing  gear  and  a  sensor  support  tripod/platform.  The  inner  shroud  ring 
serves  as  the  primary  support  structure  for  all  aircraft  subsystems,  while  the  support  struts  serve  as 
the  primary  structural  link  between  the  rotors  and  the  fuselage.  The  bulkheads  distribute  local  loads, 
such  as  engine  and  equipment  weight,  into  the  inner  shroud  ring.  The  airframe  is  sensitive  to  mass 
distribution  and  has  been  analyzed  using  finite  element  modeling  to  optimize  its  weight  and  fre¬ 
quency  response.  The  fixed  alighting  gear  is  sized  to  absorb  landing  loads  and  does  not  incorporate 
any  damping  features,  as  the  vehicle  is  unmanned.  The  fixed  sensor  mounting  tripod  supports  the 
mission  sensors  and  their  directional  control  actuators. 


B-1 


Both  the  alighting  gear  and  the  sensor  tripod  can  be  folded  and  retained  on  the  vehicle  when  the 
Air  Platform  is  stored  on  the  AMGSSS  trailer.  This  minimizes  the  amount  of  loose  equipment.  Lift¬ 
ing  lugs  are  incorporated  for  ground  handling  operations. 

PROPULSION  SYSTEM 

The  rotor  system  of  the  AMGSSS  AMP  is  based  on  a  refinement  of  the  present  Cypher  counter-ro¬ 
tating  coaxial  configuration.  Sikorsky  has  been  evaluating  methods  of  optimizing  blade  taper  and 
twist  for  the  Cypher  aircraft  using  computational  fluid  dynamics.  Each  of  the  two  4  ft.  diameter 
rotors  has  four  blades  attached  to  a  bearing-less  flex  beam.  Full  cyclic  and  collective  pitch  control  is 
provided  by  a  total  of  six  electric  servo-actuators. 

For  AMGSSS,  a  variation  of  the  Cypher  gearbox  was  incorporated  to  provide  a  gear  ratio  opti¬ 
mized  for  rotor  and  engine  performance.  A  drive  shaft  with  couplings  at  each  end  passes  through  one 
support  strut  and  transfers  power  from  the  engine  to  the  gearbox.  An  over-running  clutch  located 
between  the  engine  and  the  drive  shaft  allows  the  rotor  system  to  free-wheel  in  the  event  of  an  engine 
failure. 

The  AMP  uses  the  294  cc,  Alvis  Motors  model  NR801T  rotary  engine.  This  single  rotor  engine 
has  been  upgraded  to  incorporate  electronic  fuel  injection,  giving  it  the  ability  to  produce  60HP  at 
8000  RPM.  An  electronic-inductive  ignition  system  replaces  the  existing  CDI  unit  and  provides  a 
dual  spark  through  a  weight-saving  dual-ended  coil.  A  combination  of  liquid  and  air  cooling  is  used 
to  cool  the  block  and  rotor  respectively.  Cooling  of  the  water-glycol  liquid  is  provided  by  a  shroud 
mounted  radiator.  Fluid  is  circulated  by  a  belt-driven  pump. 

The  noise  signature  of  the  engine  will  be  dramatically  reduced  by  replacing  the  existing  ejector 
with  a  low  power  loss,  tuned,  multi-chamber  muffler.  A  centrifugal  fan  was  added  to  replace  the 
rotor  cooling  function  of  the  ejector.  Rotor  cooling  air  will  now  be  pumped  through  the  engine  via 
the  belt  driven  centrifugal  fan. 

The  fuel  system  consists  of  a  single  fuel  tank  with  an  internal  electric  pump  which  supplies  the 
lOOLL  aviation  gas  to  the  engine.  The  engine  will  also  operate  on  RON  94  or  higher  automotive  gas. 

ELECTRIC  POWER  SYSTEM 

The  AMGSSS  air  vehicle  operates  on  two  voltages:  28VDC  as  supplied  by  the  starter/  generator, 
and  12VDC  as  supplied  by  DC-DC  converters. 

The  generator  system  supplies  a  minimum  of  1200  Watts  of  28VDC  ±  10%  over  a  range  of  5000 
to  8000  engine  RPM.  Power  is  supplied  as  long  as  the  rotors  are  turning  above  the  generator’s  mini¬ 
mum  speed,  regardless  of  whether  the  engine  is  running  or  not. 

An  upgraded  power  control  unit  is  incorporated  to  supply  power  to  the  starter  and  to  condition  the 
power  coming  from  the  generator.  Power  to  drive  the  starter  is  supplied  by  onboard  batteries  when  at 
a  remote  site,  or  by  an  externally  attached  umbilical  cord  from  the  support  trailer  when  the  air 
vehicle  is  at  the  ground  station. 

The  AMP  on-station  electrical  demands  will  be  satisfied  by  a  multi-cell  battery  package  that  is 
sized  to  support  twelve  hour  duration  missions  and  associated  part-time  sensor  activity  while  running 
to  exhaustion  by  the  close  of  a  mission.  The  results  of  the  Phase  I  Mission  Power  Source  Trade  indi¬ 
cate  this  energy  storage  component  supports  a  twelve  hour  mission  scenario  and  nominal  use  of  the 
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electro-optic  sensor  equipment,  not  to  exceed  about  thirty  minutes  of  total  use  out  of  every  hour  of 
on-station  performance.  Conducting  Seismic  and  Acoustic  background  surveillance  has  been  consid¬ 
ered  a  continuous  operation  for  every  hour  of  battery  discharge. 


ALIGHTING  GEAR 

A  simple  spring-style  gear  is  mounted  to  the  structural  inner  shroud  ring  providing  energy  attenua¬ 
tion  upon  landing  and  elevating  mission  sensors  for  enhanced  performance.  The  tripod  configuration 
is  stable  in  all  situations  and  will  support  the  AMGSSS  air-mobile  platform  on  sloped  landing  sites 
up  to  30  degrees. 

Foot  pads,  illustrated  in  figure  B-3  are  used  to  minimize  ground  loads,  and  also  serve  as  mounting 
platforms  for  seismic  and  acoustic  mission  sensors.  Spring  loaded  pivots  for  the  pads  reduce  loads  on 
the  sensors,  and  provide  the  mechanism  for  ‘weight-on-wheels’  sensors  which  are  used  to  assess 
excessive  landing  site  slope. 
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Figure  B-3.  Landing  gear  foot  pad  configuration. 


Acoustic  and  seismic  sensors  are  mounted  on  the  feet  of  the  landing  gear.  The  seismic  sensor 
requires  good  contact  with  the  ground  for  optimal  function.  One  seismic  sensor  is  provided  per  air 
vehicle.  The  acoustic  sensors  are  mounted  low  to  the  ground  to  reduce  their  susceptibility  to  wind 
noise,  and  to  provide  the  widest  possible  spread  of  the  microphone  array.  One  microphone  is  located 
on  each  of  the  three  landing  gear  feet. 

Non-stmctural  hinges  allow  the  three  legs  to  be  folded  for  storage.  Captive  fasteners  are  used 
throughout,  and  no  disconnecting  of  wires  is  required  due  to  pigtail  loops  located  at  the  hinge  points. 
Foot-mounted  sensors  are  protected  from  damage  since  they  are  within  the  surrounds  of  the  shroud. 
Figure  B-4  illustrates  the  method  of  folding  and  unfolding  the  AMP  landing  gear. 

AMGSSS  MISSION  SENSOR  INSTALLATIONS 

Visual  sensors  (infrared  and  video)  are  mounted  on  a  gimbaled  platform  which  is  supported  by  a 
tripod  arrangement  above  the  vehicle  body,  and  covered  with  a  fairing.  Sensor  height  is  comparable 
to  that  of  a  man’s  eye,  roughly  six  feet.  The  azimuth  of  the  platform  varies  from  ±180  degrees,  and 
is  driven  by  an  electric  motor  through  a  reduction  gear.  Platform  elevation  is  driven  via  a  screw  jack 
mounted  to  the  tripod,  and  has  a  range  of  +30/-90  degrees  to  allow  for  a  variety  of  sloped  terrain. 

As  illustrated  in  figures  B-5  and  B-6,  the  AMGSSS  sensor  installation  supports  30-degree  slope 
landings  and  landing  site  assessment  utilizing  a  single  set  of  sensors.  An  electronic  compass  and 
inclinometer  are  mounted  on  the  platform  to  give  the  operator  spatial  orientation  cues  regardless  of 
the  position  of  the  body  of  the  vehicle. 
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Figure  B-4.  Landing  gear  fold/unfold  sequence. 


POSITION 


Figure  B-5.  Landing  site  assessment  pod  position. 


Figure  B-6.  Slope  landing  capability. 


The  sensor  pod  has  the  ability  to  look  straight  down,  allowing  the  primary  mission  sensors  to  be 
used  for  assessing  potential  landing  sights  in  any  ambient  condition.  It  can  also  be  rotated  backward 
during  flight  to  protect  the  sensor  windows  from  damage. 

The  pod  does  not  rotate  more  than  half  of  a  revolution  during  an  azimuth  scan,  eliminating  any 
requirement  for  slip  rings.  Scan  rates  are  more  than  sufficient  (360  deg/10  sec),  given  the  limited 
transmission  rate  of  the  available  non-line-of-sight  data  link. 
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Figure  B-7.  AMGSSS  pod  interior  arrangement. 


The  tripod  support  legs  are  provided  with  hinges  and  quick-release  pins  to  allow  the  pod  to  be 
folded  for  storage.  No  electrical  connectors  need  be  disconnected  due  to  a  pigtail  loop  at  the  hinge 
point  of  the  tripod  struts.  Struts  are  retained  by  the  quick  release  pins  and  dedicated  fittings.  The 
non-line-of-sight  antenna  must  be  removed  for  storage. 

AIR  VEHICLE  AVIONICS 

The  avionics  architecture  of  the  Cypher  air  vehicle,  as  currently  configured,  is  able  to  meet  all  of 
the  AMGSSS  flight  requirements  with  just  a  few  modifications  and/or  enhancements.  Figure  B-9 
illustrates  the  AMGSSS/Cypher  system  architecture.  (The  equipment  labeled  “Cypher-Specific”  on 
figure  B-9  will  be  removed  for  AMGSSS;  it  is  not  essential  for  the  mission.) 

Navigation 

The  basic  navigation  hardware  configuration  of  the  Cypher  air  vehicle  supports  all  of  the 
AMGSSS  requirements.  Due  to  degradation  in  accuracy  of  selective  availability,  however,  replacing 
the  C/A  code  GPS  with  a  P-code  GPS  will  enable  the  air  vehicle  to  maintain  a  position  hover  and  fly 
a  specified  flight  path  more  accurately.  In  fact,  in  order  to  meet  the  10-meter  positional  accuracy 
requirement,  use  of  P-code  GPS  is  required. 
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Figure  B-8.  Sensor  pod  fold  sequence. 

The  Honeywell  In  Flight  Management  Unit  (IFMU)  navigational  processing  includes  the  capabil¬ 
ity  to  generate  a  flight  path  between  two  specified  points.  It  furthermore  contains  the  ability  to  deter¬ 
mine  the  perpendicular  distance  the  air  vehicle  is  from  this  flight  path.  When  this  capability  is 
coupled  with  the  flight  control  system,  a  positional  error  of  zero  is  automatically  maintained.  Using  a 
proportional  calculation,  the  air  vehicle’s  heading  can  be  changed  according  to  how  far  off  course  the 
air  vehicle  is,  thus  automatically  accounting  for  sensor  drift  and  wind  drift. 

An  enhancement  to  the  basic  navigation  capability  will  be  addition  of  the  waypoint  database. 
Instead  of  a  single  way  point  and  a  single  flight  path  generation,  the  navigational  software  will 
receive  a  set  of  way  points.  Thus,  as  each  way  point  is  overflown,  the  IFMU  will  calculate  the  next 
leg  and  associated  heading. 

Vehicle  Management 

To  perform  the  AMGSSS  mission,  the  auto-takeoff  and  auto-landing  functions,  way  point  naviga¬ 
tion,  and  contingency  plan  functions  are  required. 

From  flight  testing  it  is  known  that  the  stability  of  the  air  vehicle  and  low  center  of  gravity  makes 
it  possible  to  command  a  preset  altitude  scheduled  descent  rate  in  support  of  auto-landing. 


B-8 


Incorporating  knowledge  of  contact  with  the  ground  (using  weight-on-wheels  type  of  switches) 
enables  a  sloped  landing  using  this  same  simple  approach. 
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Figure  B-9.  AMGSSS  system  architecture. 


APPENDIX  C:  COMMUNICATIONS 

Brett  Martin 


REQUIREMENTS 

In  1993-1994,  the  following  requirement  specification — arguably  a  “wish  list” — was  established 
for  the  AMGSSS  radio  communications  subsystem. 

Very  Reliable  Low-Rate  Communications  for  Vehicie  Controi 

The  radio  communication  system  will  provide  the  base  station  with  wireless  control  capability. 
Commands  are  sent  to  the  mobile  unit  and  status  messages  are  returned  to  the  base  station.  A  data 
rate  of  600  bits  per  second  is  adequate  for  this  task.  Latency  must  be  low — ^preferably  less  than 
1/lOth  second —  to  maximize  the  control  capabilities  of  the  base  station.  Although  the  air  vehicle  is 
designed  to  react  safely  and  predictably  in  case  of  communications  loss,  clearly  this  type  of  situation 
should  be  avoided. 

High-Speed  Data  Communications 

The  mobile  unit  is  capable  of  sending  large  quantities  of  image  data.  Ideally,  the  data  communica¬ 
tions  rate  should  be  around  100  kbits  per  second;  this  allows  the  operator  to  receive  image  updates 
nearly  every  second. 

Ability  to  Transmit  over  Terrain  without  a  Repeater 

In  the  ideal  deployment  scenario,  communication  services  are  handled  directly  between  the  mobile 
units  and  the  base  station.  If  a  relay  or  repeater  were  required,  an  additional  resource — such  as 
another  AMGSSS  mobile  unit — would  be  required. 

10-km  Range 

Ideally,  the  range  of  the  mission  should  not  be  limited  by  the  range  of  the  communications  system. 

A  range  of  10  km  is  viable  for  the  mobile  unit;  this  value  was  chosen  to  limit  the  weight  of  the  fuel  to 
an  acceptable  amount.  Therefore,  the  communication  system  should  provide  reliable  control  and 
data  transfer  at  a  10-km  range. 

Low  Weight 

The  weight  capacity  of  the  air  vehicle  is  severely  constrained.  As  the  radios  get  lighter,  the  weight 
capacity  for  batteries  increases.  With  greater  battery  capacity  comes  the  option  of  greater  transmitter 
power.  Therefore,  the  lighter  the  radios,  the  higher  the  transmit  power  and  the  greater  the  range.  A 
radio  subsystem  weight  of  2  lb  (excluding  batteries)  would  be  viable. 

Low  Power  Consumption 

Although  the  efficiency  of  a  radio  transmitter  is  determined  primarily  by  the  frequency  band  and 
waveform,  the  power  consumption  of  a  radio  receiver  is  determined  by  many  design  parameters.  For 
this  application,  the  receiver  should  be  designed  for  a  power  consumption  of  under  1  watt. 
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Small,  Light,  Omni  Antenna 

Practical  packaging  constraints  of  the  air  vehicle  prevent  the  usage  of  whip  antennas  over  1 .5  m, 
rotators  over  0.5  lb,  and  directional  antennas  of  length  or  radius  greater  than  0.3  m. 

Compatible  with  Current  Frequency  and  Protocol  Usage 

Since  this  system  is  intended  to  be  used  as  a  part  of  actual  military  missions,  it  must  not  interfere 
with  other  communications  activities.  The  frequency  allocation  and  usage  must  be  compatible  with 
standard  and  approved  military  communications  systems  that  are  or  will  be  operating  in  the  same 
frequency  band.  Ideally,  fielded  communications  systems  would  be  used  to  simplify  logistics,  train¬ 
ing,  and  maintenance. 

Compatible  with  Commercial  “PC”  Hardware  and  Software 

Commercial  “PC”  computer  hardware  and  software  is  used  in  AMGSSS.  The  data  interfaces  of 
the  radio  communications  subsystem  must  be  compatible  with  the  appropriate  interfaces  in  the 
AMGSSS  payload. 

Non-Developmental  and  Low  Cost 

The  AMGSSS  program  has  not  possessed  the  amount  of  funding  required  to  develop  a  fieldable 
communications  system.  We  have  constrained  the  cost  to  $15,000  per  “side”  of  the  communications 
link. 

OPTIONS  CONSIDERED  IN  1994 
Choice  of  Frequency  Band 

The  appropriate  frequency  band  was  determined  by  the  two  primary  constraints:  antenna  size  and 
the  requirement  for  direct  transmission  over  terrain.  The  30-88  MHz  tactical  band  is  clearly  optimal. 
At  lower  frequencies,  the  decrease  in  antenna  efficiency  and  increases  in  noise  levels  reduce  the 
signal-to-noise  ratio.  At  higher  frequencies,  the  attenuation  from  hills  and  terrain  more  than  super¬ 
sedes  the  gains  made  by  the  greater  efficiency  of  the  mobile  antenfia  and  the  added  gain  of  the  base 
station  antenna.  This  “tactical  band”  is  used  by  the  Army  and  Marine  services  for  these  same  rea¬ 
sons. 

Choice  of  Hardware 

Radio.  Radio  transceivers  used  in  commercial  applications  do  not  operate  over  such  a  broad  range 
of  frequencies,  since  it  would  not  be  possible  to  obtain  a  license  for  such  operation.  Therefore,  the 
only  non-developmental  wideband  transceivers  radios  on  the  market  are  intended  for  military 
applications. 

At  10  to  15  lb,  manpack  radios  are  far  too  heavy,  given  the  limited  payload  capacity  of  the  air 
vehicle.  Aircraft  radios  are  also  heavy,  and  they  are  not  designed  for  low  power  consumption.  We 
were  limited  to  hand-held  tactical  radios  that  could  operate  in  a  data  mode.  Of  the  world’s  hand-held 
tactical  band  military  radio  production,  there  were  none  that  could  transmit  data  rates  greater  than 
2400  bits  per  second.  However,  Racal  Communications  offered  a  prototype — a  modification  of  a 
production  radio — that  could  transmit  at  16  kbits  per  second  using  the  military  standard  radio 
modem,  the  Tactical  Communication  Interface  Module  (TCIM).  Initially,  we  tested  a  prototype  with 
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a  9800  bit  per  second  RS232  interface;  this  unit  could  be  operated  with  any  notebook  computer. 
However,  we  chose  to  buy  the  synchronous  16-kbit  version  of  the  radio  instead  for  the  virtues  of  the 
higher  data  rate  and  compatibility  with  the  other  tactical  radios  currently  in  the  field  (such  as  SINC- 
GARS).  Unfortunately,  Racal  had  not  tested  this  version  of  the  radio;  we  were  the  first  customers. 
Nevertheless,  we  decided  to  accept  this  additional  degree  of  risk. 

Computer  interface.  The  TCIMs  currently  in  the  field  are  configured  as  ISA  standard  interface 
cards.  These  are  not  suitable  for  our  application,  because  they  consume  several  watts  and,  even  more 
importantly,  require  the  usage  of  a  particular  SCSI  interface  module  that  is  no  longer  in  production. 
During  1994-1995,  Magnavox  was  preparing  to  produce  a  PC  Card  (PCMCIA)  version  of  the  stan¬ 
dard  TCIM.  They  loaned  us  a  couple  of  prototypes  to  use  during  our  development  period.  These 
units  interface  PC  computers  with  PC  Card  ports  (which  is  becoming  the  standard  configuration  for 
commercial  notebook  computers)  with  tactical  radios.  The  PC  Card  TCIM  is  not  compatible  with 
the  SCSI  TCIM  software  that  has  already  been  developed  (by  SAIC).  Since  low-level  TCIM  soft¬ 
ware  development  is  complex  and  difficult,  we  did  not  think  it  to  be  within  the  scope  of  our  effort. 
However,  Magnavox  gave  us  the  source  code  for  their  own  demonstration  software,  and  we  were 
able  to  integrate  this  code  into  our  specific  application. 

RESULTS  FROM  DEVELOPMENT  WORK  THROUGH  1995 

Choice  of  Frequency  Band 

The  characteristics  that  we  predicted  for  30-88  MHz  radio  propagation  proved  to  be  fairly  accu¬ 
rate.  Using  SINCGARS  radios  and  mediocre  antennas,  we  were  able  to  communicate  reliably  over 
hills  of  500  feet  at  distances  of  2  to  3  km.  The  maximum  range  that  we  could  achieve  at  our  hilly 
Point  Loma  site  was  5  km.  We  did  not  have  the  opportunity  to  test  the  range  over  an  open  field  to 
verify  that  10  km  was  possible. 

Choice  of  Data-Transmission  Method 

The  combination  of  the  TCIM,  tactical  radio,  and  modified  demonstration  software  proved  to  be 
usable  and  functional,  but  too  idiosyncratic  for  field  usage. 

•  Certain  types  of  data  errors  would  cause  complete  loss  of  the  communication  link,  and  the  link 
would  require  a  manual  reset.  We  could  not  duplicate  the  failures  we  experienced  in  the  field 
at  Magnavox’s  facility.  Occasionally,  data  errors  did  occur  despite  the  existence  of  error 
correction  algorithms  that  should  have  made  such  errors  impossible.  Clearly  there  is  a  need 
for  greater  refinement  in  our  software. 

•  The  “error  ft-ee”  two-way  radio  link  through  a  single  radio  frequency  created  an  immense 
amount  of  data  overhead,  software  complexity,  and  many  degrees  of  freedom  for  errors  to 
occur.  (The  single  channel  TCIM  and  accompanying  software  did  not  provide  us  with  the 
option  to  use  full  duplex.)  A  high  percentage  of  the  total  transmission  time  was  spent  by  the 
radios  merely  exchanging  blank  or  status  messages  in  order  to  maintain  the  continuity  of  the 
link.  Approximately  45  seconds  were  required  to  initialize  the  link — an  excessive  amount  of 
time  for  in-flight  link  initialization. 

•  The  effective  data  rate  was  2000-4000  bits  per  second.  Certain  operations  became  agonizingly 
slow.  We  could  double  the  data  rate  if  we  had  a  proper  scrambling  algorithm  for  ensuring  33% 
bit  transitions.  As  of  this  writing,  Magnavox  has  not  yet  completed  this  algorithm. 
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•  In  many  locations,  it  was  not  possible  to  establish  a  reliable  radio  link,  although  it  appeared 
that  such  a  link  should  be  possible.  We  blame  the  terrain  and  antenna  characteristics  for  these 
problems. 

Choice  of  Radio 

There  are  many  subtle  characteristics  of  the  Racal  radios  that  are  different  from  those  of  a  SINC- 
GARS  radio.  Although  these  differences  could  be  corrected  in  our  software,  it  is  clear  that  the  two 
radios  are  not  truly  compatible.  It  is  possible  that  Racal’s  new  Leprechaun  radio  (prototypes  are 
projected  to  be  available  in  Spring  of  1996)  will  resolve  these  compatibility  issues.  Of  greater  signif¬ 
icance  is  a  technical  defect:  The  case  and  data  port  are  effectively  unshielded,  and  radiation  from  the 
host  computer  enters  the  radio  with  enough  energy  to  reduce  the  effective  maximum  sensitivity  by 
several  orders  of  magnitude.  (The  host  computer  operates  within  the  30-88  MHz  band  and  emits  a 
considerable  amount  of  energy.  Even  if  the  computer  was  shielded,  this  energy  would  travel  down 
the  bus,  into  the  TCIM  and  finally  into  the  radio.)  As  a  result,  the  range  of  the  Racal  radios  is  con¬ 
siderably  less — 1/4  to  1/10*  the  range  of  the  SINCGARS  when  transmitting  at  equivalent  power  lev¬ 
els  with  equivalent  antennas. 

OPTIONS  AVAILABLE  FOR  1996 
Changes  in  Tactical-Band  Radios 

The  design  of  new  production  SINCGARS  radios  is  being  updated.  New  features  include  RS232 
ports  and  built-in  data  correction.  As  a  result,  it  is  no  longer  essential  to  use  a  TCIM  for  data  com¬ 
munication. 

I'l  l  is  selling  a  SINCGARS  portable  radio.  Unlike  the  Racal  unit,  it  includes  RS-232  ports  as  well 
as  MIL-STD  188-114;  frequency  hopping;  COMSEC;  and  a  remote  control  capability.  Unfortu¬ 
nately,  it  weighs  4.9  lb  (with  battery).  This  unit  should  be  seriously  evaluated  before  the  purchase  of 
any  additional  Racal  radios. 

Changes  in  Other  Wireless  Technology 

Wireless  Local  Area  Network  (WLAN)  hardware  is  becoming  a  rapidly  growing  industry.  This 
technology  is  sold  to  industry  as  a  low-cost  method  of  expanding  widely  separated  LAN  nodes. 
Equipment  is  available  in  the  unlicensed  902-  to  928-MHz  and  2.4-GHz  band.  Very  small  compo¬ 
nents  can  be  used  to  build  the  2.4-GHz  WLAN  hardware,  and  chipsets  for  PC  Card  (PCMCIA) 
construction  are  available.  For  the  AMGSSS  application,  each  surveillance  vehicle  would  be 
equipped  with  a  902-  to  928-MHz  WLAN  transceiver.  The  repeater  would  be  capable  of  receiving 
signals  from  each  surveillance  vehicle  and  multiplexing  the  data  onto  a  wider  bandwidth  2.4-GHz 
link  to  the  base  station.  The  primary  design  risk  in  building  this  system  involves  the  potential  inter¬ 
ference  between  the  multiple  902-  to  928-MHz  WLAN  units.  Since  many  different  modulation  types 
and  models  are  available — ^fixed-frequency,  direct-sequence  spread  spectrum,  and  frequency-hop¬ 
ping  spread  spectrum — a  viable  solution  is  undoubtedly  available. 

Satellite 

Low  Earth  Orbital  (LEO)  satellites  would  be  an  attractive  option  for  AMGSSS.  Although  several 
companies  are  in  the  process  of  implementing  a  commercial  system  of  this  type,  it  will  be  several 


C-4 


years  before  it  is  available.  Geostationary  satellites  require  more  transmitter  power  (or  a  larger 
antenna)  than  is  possible  with  the  AMGSSS  vehicles. 

CONCLUSIONS 

Virtues  of  VHF-Tactical-Band  Approach 

The  fundamental  question  concerning  the  design  of  the  AMGSSS  communications  subsystem  is, 
“What  frequency  band  should  be  used?”  If  the  tactical  VHP  band  is  used,  then: 

•  Repeaters  need  not  be  used  if  the  surveillance  units  are  landed  in  appropriate  places. 

•  Standard  tactical  radios  and  associated  equipment — items  in  the  field  that  are  available,  sup¬ 
ported  and  understood — may  be  used. 

•  Standard  data  security  procedures  may  be  used. 

Vices  of  VHF-Tactical-Band  Approach 

•  The  data  rate  is  low. 

•  The  standard  equipment  in  the  field  is  outside  of  the  control  of  AMGSSS.  As  a  result,  actual 
performance  and  reliability  may  not  be  as  good  as  expected. 

•  The  TCIM  requires  special  and  complex  software.  The  cost  and  support  of  special  software 
will  be  necessary  for  AMGSSS. 

•  Actual  range  and  performance  is  difficult  to  predict  in  real  scenarios.  Although  it  is  possible  to 
transmit  successfully  over  hills  and  terrain,  it  is  easier  to  fail  in  this  effort. 

•  The  computers  operate  in  the  same  frequency  band  as  the  radios.  Radiation  from  our  comput¬ 
ers — which  is  essentially  broadband  noise  from  8  to  50  MHz — significantly  reduces  the  ability 
of  the  Racal  radios  to  receive  weak  signals.  Attempts  at  shielding  the  computer  itself  were 
unsuccessful,  since  the  majority  of  the  radiation  entered  through  the  digital  interface.  Magna- 
vox  does  not  employ  any  filtering  in  the  PC  Card  TCIM.  SINCGARS  radios  do  have  effective 
shielding  at  all  ports,  and  we  had  no  reception  problems  when  these  radios  were  used. 

Virtues  of  Commercial  UHF  Equipment  Approach 

•  High  data  rates  are  possible. 

•  All  equipment  could  be  specified  and  controlled  by  the  AMGSSS  program. 

•  Little  custom  software  would  be  required.  All  low-level  functions  are  embedded  in  the  hard¬ 
ware. 

•  Direct-sequence  spread  spectrum  capabilities  provide  excellent  data  security  and  low  probabil¬ 
ity  of  detection. 

•  This  type  of  hardware  is  sold  primarily  to  business  customers.  Wireless  Local  Area  Network 
(WLAN)  hardware  is  becoming  a  rapidly  growing  industry. 

•  Very  small  and  lightweight  hardware  is  readily  available. 
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Vices  of  UHF-Band  Approach 

•  The  use  of  a  repeater  would  be  essential  in  most  circumstances.  Although  there  are  several 
possible  alternatives,  the  most  versatile  approach  would  use  one  AMGSSS  vehicle  dedicated 
to  repeater  usage.  (Since  this  vehicle  would,  by  definition,  be  located  above  the  others,  it 
could  also  be  used  to  track  a  target  once  it  had  been  detected  by  another  AMGSSS  vehicle  at  a 
closer  range.) 

•  Very  little  standard  military  equipment  could  be  used. 

•  There  is  a  potential  for  frequency  allocation  conflicts  when  used  with  other  military  opera¬ 
tions. 

•  The  radio  signal  would  attenuate  to  a  veiy  low  level  if  an  obstacle  were  placed  in  the  radio 
path.  Therefore,  a  failure  in  the  repeater  would  probably  cause  a  complete  loss  of  operation. 

In  order  to  prevent  a  complete  loss  of  the  hardware  in  this  type  of  circumstance,  a  HF  or  VHF 
backup  radio  system  must  be  included  in  all  vehicles. 

•  Transmitters  in  this  frequency  range  are  typically  fairly  inefficient,  and  therefore  the  maximum 
available  transmitter  energy  is  less  than  that  of  a  VHF  system.  However,  the  usage  of  the 
repeater  and  a  high-gain  base  station  antenna  will  extend  the  range  of  the  system  to  the 
required  levels. 

RECOMMENDATIONS 

In  1994,  the  tactical  radio  approach  seemed  to  have  the  most  merit;  The  capability  of  maintaining 
a  radio  link  without  maintaining  line  of  sight  was  considered  to  be  of  paramount  importance;  the 
standardization  of  SINCGARS  was  very  attractive;  and  the  usage  of  existing  military  communication 
protocols  very  practical.  In  practice,  a  predictable  radio  link  was  found  to  be  more  valuable  than  a 
versatile  one;  the  lightweight  SINCGARS  substitute  was  not  a  strong  performer;  and  the  existing 
protocols  were  found  to  be  inappropriate  for  our  application. 

We  could  improve  our  tactical  radio  system  by  adding  another  radio  to  create  full-duplex;  utilizing 
the  new  dual-chaimel  PC  Card  TCIM  from  Magnavox;  fixing  the  shielding  problem  with  the  Racal 
radios;  changing  our  communications  architecture  to  one  that  can  reliably  handle  data  errors  grace¬ 
fully;  and  completely  changing  the  radio  control  software.  If  these  changes  were  made,  the  data  rate 
would  increase  to  6000-8000  bits  per  second;  no  link  initialization  would  be  needed;  and  the  latency 
would  decrease  by  an  order  of  magnitude.  However,  the  actual  effects  of  real  hills  would  still  be 
somewhat  unpredictable,  and  the  data  rate  would  still  be  a  fraction  of  our  true  requirements. 

Therefore,  a  change  to  a  wireless  (UHF)  LAN  should  be  seriously  considered.  This  approach 
would  require  a  repeater  in  most  circumstances,  and  this  does  create  some  practical  disadvantages. 
However,  the  virtues  of  a  predictable  link,  straightforward  software,  and  a  high  data  rate  seem  to  be 
more  important  factors  when  the  system  is  actually  used.  For  in-flight  operation,  a  VHF  backup 
receiver  should  be  used,  but  this  would  not  add  significantly  to  the  overall  weight  of  the  payload. 

I  recommend  that  we  do  a  market  survey  to  determine  the  best  candidates  for  wireless  LAN  trans¬ 
ceivers.  Then,  we  should  try  them  and  uncover  problems  of  which  we  are  presently  unaware.  If  this 
approach  performs  well  in  the  field,  then  I  suggest  that  these  wireless  LAN  units  replace  the  current 
tactical  radio  system.  However,  it  may  be  desirable  to  retain  the  current  tactical  radio  system  hard¬ 
ware  for  in-flight  backup  communications. 


C-6 


APPENDIX  D:  SENSOR  SUITE 

Jeff  Coleman 

The  sensor  suite  must  be  able  to  view  designated  (in  azimuth  and  elevation)  sectors  or  all  of  the 
terrain  surrounding  a  deployed  system.  The  sensor  subsystem  must  detect  vehicular  traffic  or  dis¬ 
mounted  soldiers  in  the  designated  sectors  to  ensure  they  do  not  penetrate  a  protected  area  unde¬ 
tected  during  both  day  and  night  operations  and  under  a  variety  of  weather  conditions.  The  sensor 
suite  must  be  capable  of  detecting  and  identifying  ground  vehicular  targets  at  2500  m  and  personnel 
at  1000  m  during  day  and  night  operations.  The  suite  must  also  determine  range  of  targets  when 
commanded  by  the  operator.  The  video  sensors  must  be  mounted  on  a  pointing  device  that  allows 
unrestricted  observation  of  the  terrain  surrounding  the  deployed  system;  the  pointing  device  must 
also  provide  feedback  indicating  the  direction  the  sensors  are  pointing.  Because  video  sensor  opera¬ 
tion  and  video  communications  generally  require  relatively  large  amounts  of  continuous  power  and 
battery  operation  is  desired,  all  components  must  be  low  power.  An  acoustic  capability  is  an  optional 
sensor,  and  must  be  capable  of  detecting  vehicles  at  long  range  and  indicating  direction  for  camera 
pointing. 

VISUAL  IMAGING 
Requirements 

The  daylight  visual  imaging  system  is  required  to  provide  high-resolution  monochrome  images 
with  sufficient  resolution  to  allow  classification  of  vehicles  at  2.5  km  and  personnel  at  1  km.  For 
initial  panorama  capture,  a  zoom  lens  with  at  least  a  16-degree  image  width  at  the  wide  setting  is 
required. 

For  target  detection,  the  well-known  Johnson  Criteria  (reference  D-1)  for  classification  of  person¬ 
nel  or  vehicles  on  still  images  translate  to  a  requirement  for  an  8-pixel  minimum  dimension.  Assum¬ 
ing  the  worst-case  target  to  be  a  man  0.7  meter  wide  at  1  km,  the  image  will  subtend  0.04  horizontal 
degrees.  If  this  meets  the  8-pixel  requirement,  a  500-pixel-wide  imaging  chip  would  cover 
2.5  degrees.  Thus,  a  maximum  of  2.5  degrees  is  required  at  the  highest  zoom  power  if  the  imager 
provides  at  least  500  pixels  horizontally.  High  sensitivity,  dynamic  range,  and  signal-to-noise  ratio 
are  also  necessary  to  enable  reliable  long-range  detection  of  targets. 

Options  Considered 

There  is  no  shortage  of  video  camera  manufacturers  that  offer  cameras  meeting  AMGSSS  require¬ 
ments.  Kodak  high-resolution  cameras  were  rejected  as  being  too  heavy.  Sony  and  Cohu  were  the 
main  companies  considered,  with  Cohu  finally  selected. 

Canon  and  Fujinon  zoom  lenses  were  considered  to  be  readily  available  and  capable  of  meeting 
AMGSSS  lens  requirements. 

Analysis 

The  Cohu  2100  series  camera  weighs  6  oz.,  has  768(H)  by  494(V)  picture  elements,  electronic 
shutter,  20-dB  AGC,  >55-dB  signal-to-noise  ratio,  C  lens  mount,  auto  iris  output,  0.65-lux  sensitivity 
at  full  video,  3.6-W  maximum  power,  -20°  to  -i-60°C  operating  temperature,  and  shock  tolerance  of 
30  Gs  with  11 -ms  duration  in  all  three  axes.  The  package  is  small  and  output  is  RS170.  These  speci¬ 
fications  meet  all  of  the  requirements  and  provide  safety  margins. 
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The  Canon  JIOXIOREA-IAEI  zoom  lens  with  the  Cohu  camera  provides  a  field  of  view  of  3.7  hor¬ 
izontal  degrees  at  full  zoom.  Combined  with  a  2X  range  extender,  the  field  of  view  becomes 
1.9  degrees,  which  meets  the  worst-case  detection  requirements. 

Conclusions  and  Recommendations 

The  Cohu  2122-1024  camera  with  the  Canon  J 10X1 OREA-IAII  zoom  lens  and  a  2X  range 
extender  meet  all  AMGSSS  requirements  for  daylight  video. 

THERMAL  IMAGING 
Requirements 

The  thermal  imager  must  meet  the  same  requirements  as  the  visual  imaging  system  but  in  total 
darkness.  A  dual-field-of-view  lens  is  preferable  to  facilitate  observation  of  a  larger  area,  but  at  a 
minimum,  a  single  long-range  lens  is  required.  Thermal  sensitivity  of  0.1  °C  or  better  is  required  at 
the  ranges  specified.  Empirical  testing  of  cameras  has  demonstrated  that  thermal  imagers  of  lower 
sensitivity  are  difficult  to  use  at  ranges  greater  than  1  km. 

Options  Considered 

Various  options  were  considered  for  the  thermal  imager  (reference  D-2).  Image  intensifiers  were 
considered  as  an  option.  Mid-wave  versus  long-wave  infrared  imagers  were  debated.  Finally,  all 
manufacturers  of  thermal  imagers  were  contacted,  and  products  were  evaluated. 

Conclusions  and  Recommendations 

The  Inframetrics  InfraCam  with  a  100-mm  lens  was  selected.  This  imager  uses  a  platinum  silicide 
focal  plane  array  for  high  uniformity  and  a  proprietary  Stirling  cycle  dewar  cooler  to  combine  light 
weight  with  low  power  and  reasonably  high  image  quality.  The  lens  is  a  compromise  to  combine 
availability,  long  range,  light  weight,  and  low  cost  while  not  narrowing  the  view  too  much  for  pan¬ 
orama  gathering.  A  dual-field-of-view  lens  would  be  preferable,  but  may  add  $20,000  to  the  cost 
and  5  lb  or  more  to  the  weight,  depending  on  many  tradeoffs.  See  reference  2  for  more  information. 

LASER  RANGING 
Requirements 

To  determine  the  range  of  targets,  a  laser  rangefinder  must  be  included  in  the  sensor  suite.  Mini¬ 
mum  requirements  are  capability  to  reliably  determine  the  range  of  typical  military  targets  at  up  to 
2,500  m  with  10-m  accuracy.  Unit  must  be  class  1  eyesafe  and  remotely  controllable. 

Options  Considered 

About  30  reported  vendors  of  laser  rangefinders  were  contacted  and  options  were  narrowed  to  the 
following  nine  models  (table  D-1). 
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Table  D-1 .  Vendor  comparison  of  laser  rangefinders. 


Model 

Price  ($K) 

Max  Range 
(km) 

RS232 

Weight 

(kg) 

Other 

Melios 

25 

10 

no 

MM 

8300  shipped  to  Army 

Litton  Mark  VII 

30-50 

20 

yes 

■B 

GPS,  i^  scope,  compass 

Contraves 

43 

4 

yes 

0.6 

2  built  thus  far,  20  in  process 

LSDI 

23.9 

5 

yes 

1.85 

ALST  ELRF-2 

22 

10 

no 

1.8 

better  than  Melios 

SADT  Teleranger 

7.3-8.8 

1.2-2 

yes 

0.9 

LTI 

7.5 

0.8-2 

yes 

1.8 

Laser  Atlanta 

5.5 

0.61 

yes 

1.9 

compass 

Riegl  Laser  Tape 

5.7 

1.2-3 

yes 

0.9 

Notes: 


a.  Max  Range  is  only  a  rough  indication  of  range  capabilities  against  non-cooperative  targets.  Dif¬ 
ferent  vendors  use  different  measuring  techniques  and  different  target  reflectivities. 

b.  This  chart  only  includes  long-range  rangefinders. 

c.  SADT  Teleranger  price  depends  on  accuracy.  Lower  price  is  for  5-m  accuracy  and  resolution; 
higher  price  is  for  1-m  accuracy  and  0.5-m  resolution. 

Analysis 

Comparisons  are  easily  made  by  referring  to  table  D-1.  Any  of  the  first  five  units  listed  meets  the 
range  requirements.  The  Coniravcs  unit  is  significantly  lighter  than  any  of  the  others,  so  Contraves 
may  be  the  ideal  unit.  Howe\'er,  the  Contraves  price  is  the  highest,  and  availability  has  yet  to  be 
proven.  The  Melios  has  the  best  proven  track  record  in  the  military.  But  if  range  requirements  can 
be  relaxed,  one  of  the  last  four  rangefinders  in  the  table  may  be  ideal.  The  AMGSSS  Mission  Pay- 
load  Prototype  successfully  incorporated  a  Reigl  Lasertape.  It  was  found  capable  of  measuring 
ranges  of  500  to  1000  m  against  most  targets  during  the  day,  and  up  to  2600  m  at  night. 

Conclusions  and  Recommendations 

A  Contraves  laser  rangefinder  is  recommended  if  the  high  cost  is  not  prohibitive  (or  the  price  has 
dropped),  and  units  are  available.  Alternatives  include  the  Reigl  Lasertape,  if  shorter  ranges  are  suf¬ 
ficient,  or  the  Melios,  if  long  range  is  required.  Since  the  market  is  rapidly  evolving,  vendors  should 
be  contacted  again  at  the  time  of  procurement  and  new  developments  evaluated. 

AZIMUTH-ELEVATION  MOUNT 
Requirements 

The  azimuth-elevation  (or  pan/tilt)  mount  must  be  capable  of  pointing  the  video  camera,  thermal 
imager,  and  laser  rangefinder  in  any  azimuth  direction  (±180  degrees)  and  ±  30  degrees  of  eleva¬ 
tion.  This  equates  to  nearly  10  lb  of  payload.  It  must  be  capable  of  holding  its  position  without 
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vibration  and  with  little  power  consumption.  Minimum  angular  speed  should  be  60  degrees  per 
second  in  azimuth,  30  degrees  per  second  in  elevation. 

Options  Considered 

Many  azimuth-elevation  units  were  considered,  but  none  met  AMGSSS  weight,  payload,  speed, 
and  power  requirements  (reference  D-2).  Discussions  were  held  with  Orbit  Advanced  Technologies, 
Inc.  (215-674-4220),  with  News/Sports  Microwave  (619-670-0572),  and  with  Transitions  Research 
Corp.  (203-798-8988)  regarding  modifications  they  could  make  to  their  units  to  satisfy  our  require¬ 
ments.  Finally,  it  was  determined  that  the  Transitions  Research  Zebra  model  came  the  closest  and 
could  be  most  easily  modified  to  carry  the  AMGSSS  payload. 

Analysis 

The  Transitions  Research  Zebra  model  has  a  lower  specified  payload  capacity  than  AMGSSS 
requires  and  can  require  high  position  holding  power.  Both  problems  were  resolved  by  modifying 
the  pan/tilt  head,  lengthening  the  shafts,  and  adding  a  custom  camera  mount  that  balances  the  pay- 
load  around  the  pivot  point.  This  keeps  holding  torque  to  a  minimum,  requiring  little  power.  It  was 
still  necessary  to  operate  at  one  fifth  of  maximum  speed  (still  meeting  AMGSSS  speed  requirements) 
to  avoid  overloading  the  motor  controllers.  Feedback  is  through  a  relative-position  encoder,  but 
absolute  position  is  calculated  by  panning  and  tilting  to  the  stops  during  system  initialization. 

Conclusions  and  Recommendations 

The  Transitions  Research  Zebra  model  with  NRaD  modifications  meets  the  needs  of  AMGSSS 
and  is  recommended. 

ACOUSTIC  SENSOR 
Requirements 

The  acoustic  sensor  is  required  for  vehicular  target  detection  and  camera  pointing  in  areas  that  may 
not  covered  by  the  field  of  view  of  the  camera.  It  must  be  acknowledged  that  acoustic  capabilities 
will  be  highly  dependent  upon  the  operating  environment.  Factors  such  as  wind,  thermal  gradients, 
and  background  noise  will  dominate  the  system  sensitivity.  Nevertheless,  given  near  ideal  condi¬ 
tions,  the  acoustic  sensor  should  be  capable  of  consistently  detecting  operating  military  trucks  at 
ranges  up  to  1  km  and  provide  azimuth  information  accurate  to  ±6  degrees. 

Options  Considered 

Section  4.2.2  in  reference  D-3  lists  all  makers  of  acoustic  sensors  considered.  Acoustic  sensor 
data  sheets  are  available  separately. 

Analysis  and  Developments 

Northrop,  Lockheed  Sanders,  and  Alliant  Techsystems  demonstrated  working  acoustic  sensors. 
Since  none  of  the  sensors  met  the  form  factor  and  functionality  requirements  of  AMGSSS  without 
some  modification,  and  the  final  form  would  be  dependent  on  the  vehicle,  which  was  still  not  avail¬ 
able,  it  was  decided  not  to  select  and  acquire  a  specific  unit  for  the  Mission  Payload  Prototype,  but  to 
incorporate  an  RS232  interface  for  an  external  sensor.  This  allows  any  vendor  to  demonstrate  its  unit 
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in  conjunction  with  AMGSSS  tests  and  minimizes  development  costs  for  the  temporary  configura¬ 
tion.  The  Northrop  unit  was  made  available  and  successfully  tested. 

Conclusions  and  Recommendations 

Final  selection  of  an  acoustic  sensor  will  depend  on  the  AMGSSS  vehicle.  Until  then,  flexibility 
can  be  maintained  through  incorporation  of  an  extra  RS232  serial  interface  for  communication  with 
any  acoustic  sensor  system.  Several  candidates  are  available,  and  none  has  been  selected  at  this  time. 
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APPENDIX  E:  IMAGE  CAPTURE  AND  PROCESSING 

Dale  Bryan 

The  tactical  environment  places  some  unique  requirements  on  remote  video  surveillance  and  secu¬ 
rity  system  hardware.  These  systems  have  to  be  cost-effective  due  to  their  inevitable  expendability 
in  a  combat  zone.  They  have  to  be  low  power  to  operate  over  extended  duration  in  areas  where  per¬ 
sonnel  may  not  be  able  to  readily  refurbish  the  systems.  Communication  of  sensor  data  to  remote 
operators  has  to  be  transmitted  over  noisy  beyond  line-of-site  radio  frequency  (RF)  channels  using 
low  bandwidth  LPI/LPD  military  tactical  radios.  This  requires  smart  image  processing  and  robust, 
error-resilient,  data-compression  techniques  to  minimize  data  transmission  time  and  receive  the  date 
error-free. 

REQUIREMENTS 

Image  processing  plays  a  major  role  in  the  AMGSSS  program.  There  are  potentially  four  vision 
sensors  in  the  sensor  suite  for  the  AMP  including  a  FLIR,  daylight  video  camera,  and  up  to  two  land¬ 
ing  video  cameras.  The  image  processor  onboard  the  AMP  performs  various  image-processing 
tasks  during  an  AMGSSS  mission.  In  a  typical  mission,  the  image  processor  is  used  to  determine  a 
landing  spot  for  the  AMP  at  the  surveillance  location,  provide  visual  feedback  during  autoland,  per¬ 
form  video  surveillance  of  the  target  area,  enhance  image  regions  of  interest  (ROIs),  and  compress 
imagery  data  for  transmission  over  noisy  low-bandwidth  tactical  military  radio  links.  The  following 
image-processing  requirements  were  derived  for  the  AMGSSS  Program  during  1993  (reference  E-1). 

Remote  Landing  imagery 

In  the  AMGSSS  mission  scenario,  the  operator’s  first  imagery  requirement  occurs  during  the 
remote  landing  of  the  AMP.  The  platform  has  autonomously  transitioned  from  the  CDC  to  a  position 
over  a  site  previously  selected  by  the  operator.  Once  the  AMP  reaches  the  coordinates  of  that  site, 
the  operator  must  select  a  good  spot  to  autoland  the  platform.  Landing  spot  selection  will  require  the 
operator  to  visually  evaluate  the  area  under  the  hovering  AMP  to  ensure  that  it  is  free  from  obstacles, 
the  vegetation  is  not  too  high,  and  the  terrain  slope  is  not  too  great.  After  the  operator  designates  a 
landing  spot,  the  AMP  will  be  commanded  to  autoland.  During  autoland,  the  AMP  will  continually 
transmit  landing-spot  imagery  to  the  operator.  The  operator  inspects  the  images  to  verify  the  landing 
spot  is  clear. 

Image-processing  requirements  include  variable  control  of  image  size,  resolution,  and  compression 
ratio  for  landing-spot  selection,  and  video/image  compression  with  variable  control  over  frame  rate 
(e.g.,  1  frame/sec)  during  autolanding.  A  high  bandwidth  line-of-site  communications  link  may  be 
used  during  landing-site  selection  if  channel  conditions  are  suitable.  This  would  allow  real-time 
video  or  minimally  compressed  video  to  be  transmitted  directly  to  the  CDC. 

Landing  Area  Slope  Determination 

The  AMP  has  a  requirement  to  be  able  to  land  on  terrain  with  a  slope  up  to  30  degrees.  During  the 
landing  phase  of  a  mission,  the  AMP  will  be  required  to  determine  the  slope  of  a  selected  landing 
area.  Different  scenarios  are  being  evaluated  for  this  task,  including  mounting  two  downward¬ 
looking  cameras  on  the  AMP,  using  a  single  downward-looking  camera  with  inertial  positioning  to 
get  different  views  of  the  same  landing  area,  and  using  the  dayhght  surveillance  camera  on  a  pan/tilt 
unit  that  can  tilt  down  90  degrees  to  look  at  the  ground. 
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The  image  processor  will  be  required  to  register  images  from  two  cameras  or  register  different 
images  from  a  single  camera  to  perform  stereo  vision  processing  and  develop  a  depth  map  for  slope 
determination  of  the  ground  below  the  hovering  AMP.  This  function  could  also  be  done  at  the  CDC 
if  the  communications  link  data  rate  between  the  CDC  and  the  AMP  were  sufficiently  high. 

Surveillance  Image  Processing 

Once  the  AMP  has  landed,  the  AMGSSS  mission  scenario  moves  into  a  surveillance  phase.  At  the 
beginning  of  the  surveillance  phase,  a  panoramic  scene  map  of  the  surrounding  terrain  is  compressed 
and  transmitted  frame  by  frame  over  the  tactical  radio  link  to  the  CDC.  This  scene  map  is 
constructed  from  a  number  of  image  frames  segmented  together  to  form  a  wide-area  surveillance 
scene  in  both  azimuth  and  elevation.  The  operator  uses  this  panoramic  scene  map  to  pick  areas  of 
interest  to  conduct  autonomous  video  and  acoustic  surveillance  by  the  AMP  during  its  mission. 
Image-processing  functions  during  the  surveillance  phase  include  ROI  selection,  image  enhance¬ 
ment,  video  motion  detection,  and  image/video  compression. 

Image  Preprocessing.  The  image  processor  will  be  required  to  do  a  number  of  preprocessing  tasks 
depending  on  the  changing  scene  conditions  during  the  surveillance  phase  of  a  mission.  These  func¬ 
tions  include  electronic  image  stabilization  to  compensate  for  induced  global  frame  jitter  from  wind, 
image  contrast  enhancement  for  those  times  during  the  day  when  the  image  scene  has  low  signal-to- 
noise  ratio,  image  edge  enhancement  for  aiding  operator  location  of  man-made  targets  in  the  scene, 
sensor  fusion  for  image  enhancement,  and  filtering  for  image  noise  reduction. 

Regions  of  Interest  Imagery.  Multiple  ROIs  are  required  during  a  surveillance  phase  to  optimize 
video  motion  detection  on  the  AMP,  and  minimize  image  transmission  time  to  the  CDC.  ROIs  are 
constructed  of  arbitrary  width  and  height  within  an  image  frame  or  multiple  frames.  The  ROIs  repre¬ 
sent  high-interest  areas  (e.g.,  roads)  as  well  as  exclusion  areas  for  video  motion  detection.  ROIs  are 
used  in  image  transmission  to  send  high-resolution  subimages  at  faster  update  rates  to  the  CDC  over 
low  bandwidth  tactical  radio  Unks.  These  ROIs  are  pasted  into  the  operator’s  panoramic  scene  map. 
When  used  in  conjunction  with  video  motion  detection,  a  high-resolution  ROI  containing  a  moving 
target  of  interest  can  be  transmitted  to  the  CDC  continuously  in  re|l-time  and  pasted  into  the  static 
scene  map  to  provide  a  real-time  display  of  moving  targets. 

Video  Motion  Detection.  Video  motion  detection  along  with  acoustic  detection  are  used  by  the 
AMP  as  cueing  mechanisms  for  the  operator.  Video  motion  detection  is  performed  on  the  AMP 
without  any  interaction  with  the  operator,  except  for  initial  parameter  setup.  Initial  parameter  setup 
includes  which  image  segments  and  ROIs  within  a  surveillance  panorama  will  be  used  for  video 
motion  detection.  Thresholds,  dwell  time,  time  on  target,  and  sensor  are  assigned  for  each  given 
region.  This  information  is  sent  to  the  AMP  as  a  program  that  will  be  executed  autonomously  once 
commanded  by  the  operator.  When  motion  is  detected,  the  image  processor  alerts  the  operator  with 
the  programmed  response,  either  an  image  of  the  target,  video  stream,  laser  range  to  target,  or  audi¬ 
ble  tone.  The  AMGSSS  program  has  a  requirement  of  detecting  personnel  motion  at  a  range  up  to  1 
km  and  vehicle  motion  at  a  range  up  to  2  km.  A  further  requirement  of  the  video  motion  detector  is 
to  discriminate  between  random  environmental  motion  and  directed  target  motion,  thereby  reducing 
false  alarm  rates. 

Image/VIdeo  Compression.  The  most  important  function  for  the  image  processor  is  image/video 
compression  of  video  surveillance  imagery  for  transmission  over  low-bandwidth,  noisy  tactical  radio 
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links.  A  greyscale  still  image  of  size  512  by  480  at  8  bits  represents  approximately  2  million  bits  of 
data.  The  AMGSSS  program  has  targeted  a  16-kbps  tactical  RF  data  link  between  AMP  and  CDC. 
The  radios  of  choice  are  the  Army’s  Single  Channel  Ground-Air  Radios  (SINCGARS),  which 
although  operating  at  a  digital  data  rate  of  16  kbps,  effectively  pass  data  at  more  like  4  kbps.  With¬ 
out  image  compression,  it  would  take  8.3  minutes  to  transmit  the  above  image  across  a  realistic 
SINCGARS  link.  Using  a  standard  still-image  compression  scheme  such  as  JPEG  or  NITFS  2.0,  this 
same  image  can  be  lossy  compressed  at  -15:1  without  perceptible  degradation  and  transmitted  over 
this  same  link  in  33  seconds.  Improvements  of  3  to  5  times  more  compression  are  achievable  for 
more  advanced  still-image  compression  algorithms  like  wavelets  for  the  same  perceivable  image 
quality.  Further  improvements  can  be  achieved  if  video-compression  algorithms  like  H.263M  or 
MPEG  IV  are  used. 

The  image  processor  is  required  to  compress  still  images  at  various  sizes  and  resolutions  in  such  a 
way  as  to  maintain  error  resiliency  and  robustness  when  transmitted  over  a  noisy  RF  radio  channel. 
Compression  ratio  is  selectable  by  the  operator.  Further,  robust  video  compression  algorithms  are 
required  for  sending  near  real-time  video  streams  of  regions  of  interest  at  better  than  1  frame/sec. 

Low  Weight 

The  AMP  has  a  payload  weight  restricted  to  <  60  lb.  This  weight  includes  batteries  needed  to  pro¬ 
vide  power  for  the  sensor  payload.  The  image  processor  must  be  developed  using  highly  integrated 
processors,  DSPs,  and  ASICs  to  keep  its  weight  down  without  sacrificing  performance.  A  target 
weight  for  the  image  processor  is  <10  lb. 

Low  Power  Consumption 

Power  translates  to  weight  on  the  AMP.  The  image  processor  must  take  advantage  of  highly  inte¬ 
grated  low-power  programmable  vision  processor,  DSP,  and  ASIC  technologies  to  provide  the  func¬ 
tional  image-processing  requirements  of  the  AMGSSS  program  and  yet  maintain  low  power  con¬ 
sumption  at  the  same  time.  Power  consumption  for  the  image  processor  is  targeted  at  <10  W. 

Low  Cost 

The  AMP  has  a  targeted  cost  of  <$100K.  Ideally,  the  AMP  is  cheap  enough  since  its  expendability 
during  a  mission  is  a  consideration.  At  this  cost  level,  the  image  processor  must  be  <$10K  to  $15K 
to  be  cost  effective  for  the  AMP. 

OPTIONS  CONSIDERED  FOR  AMGSSS 

Investigations  into  leading  image/video  compression  and  video  motion  detection  approaches  were 
conducted  through  database  searches,  attending  relevant  conferences,  and  direct  contact/demonstra¬ 
tions  of  institutions  involved  in  these  areas  of  research  and  development.  Most  of  this  effort  was  per¬ 
formed  during  1992-94  (reference  1).  Approaches  that  showed  similarity  to  AMGSSS  program 
image-processing  requirements  were  highlighted  in  this  smdy.  A  major  point  from  this  investigation 
was  that  there  were  no  institutions/vendors  developing  systems  that  met  all  of  AMGSSS’s  image- 
processing  requirements.  There  was  only  one  system  that  even  integrated  video  motion  detection 
with  image  compression.  This  system  was  developed  by  Army  Research  Lab/Oak  Ridge  National 
Lab  for  the  UGV  Demo  I  program.  This  system  was  power  consuming  and  bulky  since  there  were 
no  restrictions  on  weight  and  power  for  that  program.  Image  processing  for  AMGSSS  has  to  be  a 
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highly  integrated  solution  combining  image/video  compression,  video  motion  detection,  and  image- 
processing  functions  because  of  restrictions  on  power,  weight,  and  cost. 

Still  Image  Compression  Technoiogy 

One  of  the  AMGSSS  image  processor’s  main  tasks  is  two-dimensional  spatial  compression  of  a 
captured  image  frame.  This  enables  surveillance  and  security  imagery  to  be  transmitted  across  a 
low-bandwidth  tactical  data  link  in  reasonable  times.  Efficient  coding  techniques  for  imagery  has 
been  the  subject  of  research  and  development  for  many  years.  The  three  most  popular  techniques  for 
spatial  compression  are  the  discrete  cosine  transform  (JPEG),  fractal,  and  wavelet-based  algorithms. 

JPEG.  The  JPEG  algorithm  is  based  on  the  discrete  cosine  transform  (DCT).  This  algorithm  codes 
an  image  frame  8  by  8  pixel  blocks  at  a  time.  The  algorithm  was  developed  in  the  1970s  and 
matured  through  the  1980s  when  it  was  developed  into  standards:  JPEG  for  the  commercial  world 
and  Nl'l'ES  2.0  for  the  DoD  world.  It  is  a  symmetric  algorithm,  which  means  the  encoder  and 
decoder  have  essentially  the  same  complexity.  The  algorithm  has  good  subjective  compression  per¬ 
formance  for  image-compression  ratios  <30  to  40:1,  but  degrades  rapidly  at  higher  compression 
ratios.  Degradation  is  in  the  form  of  blocky  artifacts  due  to  the  nature  of  its  block  transform  algo¬ 
rithm.  It  has  the  advantage  of  standardization,  which  enables  it  to  be  transportable  over  many  sys¬ 
tems,  both  commercial  and  military.  There  are  a  lot  of  products,  both  software  and  hardware,  that 
use  JPEG. 

Fractal.  Fractal  compression  is  based  on  algorithms  that  exploit  self-similarity  within  an  image. 

This  algorithm,  like  JPEG,  breaks  an  image  up  into  contiguous  blocks,  but  unlike  JPEG,  these  blocks 
can  vary  in  size  and  shape.  Fractal  algorithms  have  been  developing  since  the  mid  1980s  and  have 
not  yet  matured.  The  algorithm  is  highly  asymmetric  whereby  the  encoder  is  much  more  complex 
than  the  decoder.  This  is  due  to  the  process  of  analyzing  the  input  image  to  determine  the  different 
self-similar  basis  blocks.  However,  fractal  decompression  is  fast.  Fractal  compression  has  good  sub¬ 
jective  performance  for  compression  ratios  <60  to  80:1,  but  compares  quantitatively  about  the  same 
with  adaptive  DCT  (reference  2).  Degradation  is  in  the  form  of  blockiness  and  geometric  distortions. 
The  fractal  approach  offers  no  advantage  to  AMGSSS  due  to  its  slow  compression  performance. 
Similar  findings  about  the  fractal  algorithm  have  been  seen  at  the  Army  Research  Lab.  There  are  a 
few  companies  making  software  and  hardware  products  based  on  the  fractal  algorithm.  These 
include  Fed-Comm  and  Iterated  Systems,  Inc.  (ISI).  Fed-Comm  uses  ISPs  fractal  encoder  chip  on  its 
PC-based  product. 

Wavelet.  The  wavelet  algorithm  is  part  of  a  larger  class  of  multiresolution  algorithms  including  sub¬ 
band  coding  and  pyramid  coding.  These  algorithms  are  transform-based  like  the  DCT,  but  operate 
over  the  entire  image  instead  of  block  by  block.  The  wavelet  algorithm  has  been  developing  since 
the  mid  1980s  and  has  not  yet  matured.  The  algorithm  is  symmetric  and  computationally  faster  than 
the  DCT.  This  algorithm  shows  good  subjective  compression  performance  for  compression  ratios 
<100  to  150:1.  Degradation  is  in  the  form  of  defocused  areas  and  mosquito  noise  within  the  image. 
The  wavelet  algorithm  looks  like  the  best  compression  technology  to  date  for  the  AMGSSS  program. 
The  wavelet  algorithm  offers  a  3  to  5  improvement  in  compression  performance  over  JPEG  for  the 
same-subjective  image  quality.  It  is  a  faster  and  less  complex  algorithm  to  implement  than  JPEG. 
Progressive-resolution  image  transmission  is  built  into  the  algorithm,  which  is  an  important  feature 
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for  low-bandwidth  data  links.  A  disadvantage  of  the  wavelet  algorithm  is  that  it  is  not  part  of  a  stan¬ 
dard  at  this  time.  Similar  studies  of  compression  technology  have  been  done  for  the  military  show¬ 
ing  wavelets  to  be  the  best  choice  to  date  for  applications  similar  to  that  of  the  AMGSSS  program 
(reference  3).  Companies  have  begun  selling  software-  and  hardware-based  wavelet  products. 

These  companies  include,  Summus,  Mac  A.  Cody  Associates,  Aware/ Analog  Devices,  Fastman, 
HDS,  and  Magnovox/Hughes. 

Video  Compression  Technoiogy 

Video  compression  technology  incorporates  an  additional  temporal  dimension  for  compression  in 
conjunction  with  the  two-dimensional  spatial  approaches  mentioned  above.  This  provides  much 
greater  compression  ratios  for  image  data  than  spatial  compression  alone.  Much  of  the  information 
within  an  image  frame  and  between  successive  frames  in  a  video  sequence  is  redundant.  In  video 
compression,  intraframe  redundancy  is  reduced  using  spatial-compression  techniques,  while  inter¬ 
frame  redundancy  between  frames  is  reduced  using  temporal-compression  techniques.  Table  E-1  lists 
the  current  commercial  video  compression  standards. 


Table  E-1 .  Commercial  video  compression  standards. 


Standard 

Data  Rate 

Application 

H.263(H.324) 

<28.8  kbps 

Videophone  on  PTSN 

H.261  (H.320) 

56  kbps  to  1 936  kbps 

ISDN  video  teleconferencing 

MPEG  1 

1.5  Mbps 

CD-ROM  applications 

MPEG  II 

4  Mbps  to  20  Mbps 

Broadcast  TV,  HDTV,  DBS 

All  of  these  algorithms  are  based  on  DCT  compression  for  intraframe  coding  and  some  predictive 
coding  scheme  with  optional  motion  estimation/compensation  for  the  interframe  coding  strategy. 
Some  upcoming  standards  in  the  video  compression  area  for  low-bit-rate  wireless  data  links  are  the 
extension  of  H.263  to  H.263M  by  making  it  more  error  resilient  to  the  noisier  wireless  channels;  and, 
the  development  of  MPEG  IV,  currently  scheduled  for  1998  standardization.  MPEG  IV  has  remote 
video  surveillance  called  out  as  one  of  its  application  areas  and  it  is  also  concerned  with  algorithm 
robustness  in  the  presence  of  a  noisy  channel.  An  error  resilient  technique  that  is  competing  for 
inclusion  in  the  MPEG  FV  standardization  process  was  shown  to  be  quite  effective  in  side  by  side 
comparisons  against  baseline  H.263  for  a  simulated  channel  having  a  random  bit-error  rate  of  0.001 
and  burst  errors  of  16  msec  and  24  msec  (reference  5).  Besides  the  video  compression  standards 
mentioned  above,  there  exist  proprietary  schemes  implemented  by  various  companies.  The 
AMGSSS  program  either  purchased,  borrowed,  or  saw  demonstrations  of  the  following  systems  dur¬ 
ing  its  evaluation  of  candidate  video  compression  technologies. 

IIT’s  DVC3.  Integrated  Information  Technology  has  developed  a  programmable  vision  processor  IC, 
the  VCP,  that  contains  seven  function-specific  processors  on  a  single  chip.  The  VCP  eonsumes 
2  watts  of  power.  HT  sells  the  chip  to  OEMs.  An  evaluation  board  is  available  for  the  PC  ISA  bus 
that  demonstrates  the  VCP’s  capabilities  in  implementing  H.320,  H.261,  H.263,  MPEG  I  video  eom- 
pression/deeompression,  and  MPEG  n  decompression.  The  VCP  also  comes  with  JPEG  code  for 
still-image  compression.  Data  rates  are  programmable  down  to  4800  bps.  Compressed  video  data 
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are  passed  across  the  PC  ISA  bus  at  the  programmed  data  rate  and  either  written  to  files  or  looped 
back  to  the  VCP  for  real-time  decompression  and  display.  The  VCP  can  perform  video  compression 
and  decompression  simultaneously  in  real  time.  The  DVC3  board  is  configured  to  demonstrate 
video  teleconferencing  (voice,  video,  and  data).  Video  compression  parameters  for  the  DVC3  demo 
board  such  as  frame  rate,  compression  ratio,  intraframe  coding  refresh  rate,  and  image  size  are 
adjustable  in  real  time  using  a  PC -hosted  interface  program  over  the  PC  ISA  bus.  Its  programmable 
nature  makes  it  suitable  for  developing  and  integrating  new  algorithms  for  still-image  compression, 
video  compression,  image  enhancement,  and  video  motion  detection. 

ISI’s  Video  Teleport  System.  Iterated  Systems  Inc.  has  developed  a  fractal  video  compression 
product  that  runs  on  a  PC.  This  commercial  product  is  a  result  of  SBIR  work  under  contract  to  the 
Army.  ISI  developed  a  fractal  ASIC  for  implementing  the  complex  fractal  encoder,  while  the  fractal 
decompressor  is  a  software-only  solution.  The  system  allows  control  of  image  size,  image  scaling, 
and  data  rate.  The  Video  Teleport  transmits  the  compressed  video  stream  out  the  PC’s  RS232  port. 
The  compression  PC  consists  of  a  frame-grabber  board,  fractal-encoder  ASIC  board,  and  Windows- 
based  encoder/decoder  software.  There  is  no  control  over  compression  ratio;  rather  this  was  fixed  by 
ISI,  based  on  quality  tests  performed.  ISI  uses  a  proprietary  method  for  temporal  compression  that 
incorporates  fractal  compression  of  difference  frames.  This  system  has  not  progressed  much  since 
1993,  which  was  about  the  time  the  Army  stopped  funding  ISI  in  favor  of  wavelet-based  compres¬ 
sion  approaches. 

SNL  ITS  System.  Sandia  National  Laboratory  has  developed  the  Image  Transmission  System  (ITS) 
for  the  Department  of  Energy  (DOE).  This  system  uses  commercial  JPEG  software  for  intraframe 
coding  and  a  proprietary  frame-differencing  approach  for  interframe  coding  successive  frames.  The 
ITS  uses  a  PC  ISA  bus  image  frame  grabber  with  software  mnning  under  MS-DOS.  Compressed 
video  data  is  transmitted  out  the  PC’s  RS-232  port.  The  ITS  has  been  demonstrated  using  telephone 
modems  and  a  spread-sprectmm  radio  modem.  The  ITS  was  developed  to  supplement  physical  secu¬ 
rity  systems  currently  in  use  at  DOE  facilities.  The  ITS  is  also  available  in  a  low-cost  embedded 
configuration.  Sandia  has  investigated  improvements  to  the  ITS  including  progressive  image  trans¬ 
mission,  image  postprocessing,  and  algorithm  modifications  for  error-resilient  image  transmission. 

DIS’s  Demo  I  System.  Delta  Information  System  developed  a  video  compression  system  under 
contract  to  TACOM  for  the  UGV  program’s  DEMO  I.  DIS’s  video  compression  system  uses  DCT 
for  its  intraframe  coding  and  frame  differencing  for  its  interframe  coding.  The  operator  has  control 
over  the  data  rate,  frame  rate,  and  resolution.  The  system  is  implemented  in  rack-mounted  VME 
hardware  weighing  50  lb  and  using  150  watts.  Delta  Information  Systems  delivered  their  system  to 
TACOM  in  January  1993.  This  system  has  remained  unfunded  and  unused  since  then. 

Delta  Information  System  introduced  (Fall  1995)  a  new  video  compression  product  called  the 
Vidicoder.  The  Vidicoder  is  a  single  3-inch  by  5-inch  board  containing  m’s  VCP  vision  processor. 
The  Vidicoder  consumes  3.5  watts  and  uses  the  H.320/H.324  video  teleconferencing  compression 
standard.  The  Vidicoder  compression  algorithm  can  be  modified  since  the  VCP  is  programmable. 
The  operator  has  control  over  frame  rate,  data  rate,  image  size,  and  compression  ratio.  Data  are  out¬ 
put  as  a  RS-422  serial  bit  stream.  The  Vidicoder  costs  $5.5K.  This  type  of  product  offers  great 
potential  for  addressing  the  image-processing  requirements  for  the  AMGSSS  program,  especially  in 
terms  of  cost,  power,  and  weight. 
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ARL/ORNL’s  Demo  I  System.  The  Army  Research  Lab/Oak  Ridge  National  Lab  video  compres¬ 
sion  system  was  developed  for  the  UGV  program  and  demonstrated  during  DEMO  I  in  1992.  The 
video  compression  algorithm  uses  pyramid  intraframe  coding  with  frame  differencing  for  the  inter¬ 
frame  coding.  This  system  had  a  fixed  data  rate  of  64  kbps.  It  is  implemented  in  rack-mounted 
VME  hardware  weighing  50  lb  and  using  150  watts.  At  last  check,  this  system  remained  unfunded 
since  its  demonstration  at  DEMO  I. 

There  were  a  few  other  video  compression  systems  that  were  not  yet  available  at  the  time  of  this 
investigation  from  companies  including  Fed-Comm,  Magnavox,  C-Cube,  array  Microsystems,  and 
HDS.  Products  like  the  IIT’s  DVC3,  C-Cube’s  CL4000,  and  DIS’s  Vidicoder  provide  a  high- 
performance,  flexible  approach  to  implementing  and  upgrading  video  compression  solutions  for  the 
AMGSSS  program. 

Video  Motion  Detection  Technology 

Video  motion  detection  is  performed  by  the  image  processor  on  the  AMP.  Autonomous  video 
motion  detection  plays  a  key  role  for  the  AMGSSS  program.  It  relieves  the  remote  operator  from 
continuously  monitoring  surveillance  imagery  during  a  mission,  and  greatly  reduces  the  tactical  com¬ 
munications  requirements  between  the  AMP  and  the  CDC  during  the  course  of  a  mission,  thereby 
maintaining  low  probability  of  detection  (LPD). 

DSRC’s  VFE-100.  David  Samoff  Research  Center  developed  the  Vision  Front  End  (VFE)  through 
contracts  with  the  U.S.  Army  Missile  Command  (MICOM).  The  VFE-100  performs  video  motion 
detection  and  tracking.  It  also  is  capable  of  image-processing  tasks,  including  image  stabihzation 
from  a  moving  platform,  sensor  fusion  (FLIR/TV),  subpixel  resolution  techniques,  and  target  recog¬ 
nition.  The  VFE-100  is  based  on  multiresolution  techniques  (pyramid)  for  image  decomposition  and 
image  processing.  The  VFE-100  hardware  consists  of  rack-mounted  VME  cards  weighing  20  lb  and 
consuming  150  watts.  DSRC  formed  a  subsidiary,  Sensar,  to  market  the  VFE-100  commercially. 

The  VFE-100  was  part  of  the  UGV  program’s  DEMO  n  demonstration.  At  the  core  of  the  VFE-100 
is  the  PYR I  chip.  Several  of  these  ASICs  performs  the  pyramidal  image  decomposition  and  proces¬ 
sing  on  the  input  video  signal  in  real  time.  This  chip  could  also  be  used  for  wavelet  image-compres¬ 
sion  techniques.  The  MDARS  program  contracted  DSRC  in  1994  to  develop  a  downsized  version  of 
the  VFE-100  for  target  motion  detection  from  a  moving  platform.  DSRC  also  submitted  a  proposal 
to  AMGSSS  in  1994  to  develop  an  integrated  image  processor  based  on  a  downsized  VFE-100.  This 
system  would  perform  all  of  the  AMGSSS  image-processing  tasks,  compression,  motion  detection, 
slope  determination,  and  image  preprocessing,  on  a  single  6U  VME  card  consuming  30  watts.  The 
proposal  was  based  on  the  development  of  second-generation  versions  of  the  PYR  I  ASIC.  The 
AMGSSS  program  was  not  in  a  position  to  fund  any  subsystem  development  at  that  time.  DSRC 
finished  a  second-generation  PYR  n  chip  development  in  1995. 

ARL’s  ATA  System.  A  group  at  the  Army  Research  Laboratory,  formerly  from  Harry  Diamond 
Laboratories,  has  developed  an  Automatic  Target  Acquisition  (ATA)  system  through  funding  from 
the  UGV  program.  ARE  teamed  with  ORNL  for  the  UGV’s  DEMO  I  tests  in  1992.  ARE  provided 
the  video  motion  detection  and  tracking  capabilities  for  the  system  while  ORNL  did  the  video  com¬ 
pression  tasks  .  The  ATA  was  implemented  in  rack-mounted  VME  hardware.  ARL  also  used 
DSRC’s  VFE-100  for  image  stabilization  and  registration  tasks.  This  work  was  not  continued  by  the 
UGV  program  after  DEMO  I. 
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NRL.  Naval  Research  Laboratory  (NRL)  is  developing  VMD  algorithms  based  on  optical-flow 
methods.  This  work  was  established  using  IR  funding.  It  has  been  proposed  for  vehicle  detection 
and  speed  monitoring  for  IVHS  and  demonstrated  for  wide-area-surveillance  applications.  The  algo¬ 
rithms  are  currently  workstation-based. 

SNL/NMSU.  Sandia  National  Laboratory  (SNL)  is  developing  video  motion  detection  algorithms 
for  both  daylight  and  FLIR  sensors.  This  work  is  being  funded  by  DOE  and  DNA  for  facilities’ 
physical  security  applications.  SNL  has  developed  VMD  algorithms  that  have  been  transitioned  to 
embedded  hardware.  SNL  has  demonstrated  VMD  algorithms  running  on  PC-based  and  STD32  bus 
architectures.  SNL  is  teaming  with  New  Mexico  State  University  (NMSU),  which  is  developing 
knowledge-  based  tracking  algorithms  to  work  in  conjunction  with  SNL’s  VMD  algorithms. 

In  addition  to  the  ongoing  VMD  work  at  Sandia,  there  is  a  group,  the  Intrusion  Detection  Technol¬ 
ogy  Department,  tasked  with  evaluating  commercial  VMD  products  for  DOE.  This  group  reports  on 
the  performance  of  commercial  VMD  systems  for  detecting  intruders  in  an  exterior  setting  at  ranges 
out  to  250  feet  from  the  camera  (reference  5). 

Low-Power,  Lightweight,  Cost-Effective  Solutions 

The  optimum  solution  in  terms  of  weight,  power,  cost,  and  performance  for  an  AMGSSS  image 
processor  is  a  programmable  vision  processor  in  conjunction  with  the  large  market  base  of  COTS- 
embeddable-hardware  bus  architectures  (VME,  STD32,  PCI,  ISA,  PC/104).  Programmable  vision 
processors  are  highly  integrated  inexpensive  chips/chipsets  that  perform  a  variety  of  image- 
processing  tasks  using  multiple  processors  on  a  single  chip  while  consuming  only  a  couple  of  watts. 
Although  the  chips  are  inexpensive,  the  development  tools  for  these  chips  can  range  in  cost  from 
$20K  to  $100K.  These  multiprocessor  chips  are  categorized  into  two  groups,  heterogenous  and 
homogenous  processors  (reference  6).  Homogenous  processors  are  multiple  versions  of  the  same 
processor  on  a  single  chip,  while  heterogenous  processors  are  multiple  processors  on  a  chip  (each 
processor  is  optimized  for  a  specific  function).  A  heterogenous  vision  processor  is  more  capable  if  a 
given  image-processing  task  and  power  requirement  than  a  homogenous  vision  processor  due  to  the 
function-specific  nature  of  a  heterogeneous  vision  processor.  However,  it  is  less  flexible  to  pro¬ 
gram  than  a  homogenous  vision  processor. 

A  vision  processor(s)  could  be  programmed  to  perform  all  of  the  AMGSSS  image-processing 
tasks,  including  image  compression,  video  compression,  motion  detection,  slope  determination, 
image  enhancement,  and  image  stabilization.  Several  vision  processors  were  investigated  for  the 
AMGSSS  program,  including  IIT’s  VCP  chip,  C-Cube’s  CL4000  chipset,  array  Micosystem’s  Video- 
Flow  chipset,  and  Texas  Instrument’s  TMS320C80  chip.  An  ISA  bus  demo  board  with  DT’s  VCP 
heterogenous  vision  processor  chip  was  purchased  and  evaluated.  At  the  time  of  this  investigation, 
C-Cube,  array  Microsystems,  and  Texas  Instruments  products  were  not  available  yet.  The  VCP 
demo  board  came  with  programs  that  performed  JPEG  still-image  compression,  H.261  and  H.320 
video  compression,  image  scaling,  and  image-resolution  control.  One  of  the  seven  onboard  proces¬ 
sors  of  the  VCP  is  a  block  matching  processor  used  in  motion  estimation  for  video  compression 
algorithms.  This  processor  could  be  programmed  for  video  motion  detection  for  AMGSSS.  The  IIT 
VCP  development  tools  cost  $80K.  When  normalized  for  H.261  video  compression  performance, 
the  VCP  provided  the  best  performance  versus  chip  silicon  area  (power)  for  a  variety  of  VLSI  vision 
processor  architectures  (reference  6). 
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AMGSSS  Image-Processing  Evaluation  Videotape 

Video  data  were  collected  at  Fort  AP  Hill  in  Virginia  and  Camp  Pendleton  in  California.  This 
video  data  included  representative  imagery  for  a  wide  range  of  AMGSSS  mission  scenarios.  Light¬ 
ing  conditions  included  day,  night,  dusk,  dawn,  and  backlit  settings.  Weather  included  sunny, 
cloudy,  rainy,  dusty,  windy,  and  smoky  conditions.  Environmental  conditions  included  meadows, 
woods,  desert,  and  urban  terrain.  Both  daylight  and  FLIR  video  was  taken  for  all  scenarios  with 
moving  targets  including  personnel,  cars,  trucks,  HMMWVs,  tanks,  APCs,  and  helicopters.  Target 
ranges  were  0.5  to  2  km  for  personnel,  and  0.5  to  5  km  for  vehicles.  Video  data  were  edited  into  a 
videotape  that  can  be  used  to  evaluate  vendor  systems  performance  for  meeting  AMGSSS  image- 
processing  requirements. 

OPTIONS  CONSIDERED  FOR  THE  MPP  IMAGE  PROCESSOR 

In  1995,  the  AMGSSS  program  changed  direction  due  to  funding  restrictions.  It  was  decided  to 
develop  a  mission  payload  prototype  (MPP)  sensor  subsystem  with  a  corresponding  laptop-based 
operator  console  (reference  7).  The  development  concept  was  to  put  together  low-cost  COTS  hard¬ 
ware  and  software  that  were  available  at  the  time  within  the  power  and  weight  constraints  of  the  cur¬ 
rent  AMP  platform.  Furthermore,  it  was  decided  to  package  the  hardware  in  a  suitcase-type  form 
that  would  easily  fit  under  a  commercial  airline  seat. 

Rapid  prototyping  was  another  driving  factor  in  the  MPP  development  due  to  midyear  arrival  of 
FY  95  funding.  To  facilitate  rapid  prototyping  of  the  MPP  hardware  and  software,  several  key 
design  decisions  were  made: 

•  Leverage  development  off  the  large  COTS-embedded  PC-hardware  market. 

•  Minimize  software  development  time  by  using  available  COTS  software  libraries  and  drivers. 

•  Distribute  MPP  tasks  into  functional  processing  elements  that  are  scalable. 

•  Facilitate  MPP  virtual  system  design  by  implementing  TCP/IP  for  interprocessor  communica¬ 
tions  and  using  the  Internet  during  development  and  testing. 

Driven  by  the  above  criteria,  the  options  considered  for  MPP  image  processor  (IP)  were 
constrained  to  variations  of  readil)  available  PC-based  COTS  hardware  and  software  products. 
Alternatives  for  the  IP  fell  into  the  three  categories  discussed  below. 

Option  1 :  X86  Hardware/Software 

This  option  consists  of  ISA  and  PC/104  bus  adapter  boards  controlled  by  a  host  X86  (386,  486,  or 
Pentium)  processor  through  DOS-based  software  tools.  The  X86  processor  can  reside  on  either  a 
single  board  computer  card,  ISA  adapter  card,  or  a  PC/104  card.  Software  tools  include  libraries  and 
drivers  that  come  with  the  various  hardware  adapter  boards  (e.g.,  frame  grabber)  and  an  X86  C  com¬ 
piler  for  custom  code  development.  This  approach  was  the  lowest  risk  because  of  the  large  product 
base  in  both  hardware  and  software  solutions  available  for  the  PC  market.  It  was  also  the  most  flex¬ 
ible  approach  because  the  existing  IP  hardware/software  components  can  be  easily  upgraded  as  new 
and  more  capable  PC-based  hardware/software  products  (e.g.,  better  compression  library)  become 
available.  This  option  represents  the  lowest  performance  of  the  three  due  to  the  execution  speed  of 
the  X86  microprocessor  in  performing  image-processing  tasks,  and  data  transfer  rates  across  the  ISA 
bus.  Option  1  costs  range  up  to  ~$5K. 
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Option  2:  X86  +  DSP  Hardware/Software 

This  option  consists  of  an  X86  host  processor  working  in  conjunction  with  a  DSP  coprocessor  ISA 
or  PC/104  bus  board.  This  option  requires  two  software  development  environments.  One  for  the 
X86  microprocessor  and  another  for  the  DSP  chip,  each  with  its  own  compilers,  debuggers,  drivers, 
and  libraries.  This  option  is  less  flexible  than  Option  1  in  the  sense  that  there  are  less  COTS  prod¬ 
ucts  available  for  a  given  DSP  chip  than  there  are  for  PC-based  X86  processors.  Option  2  offers  bet¬ 
ter  performance  over  Option  1  because  IP  image-processing  algorithms  will  run  faster  on  a  DSP,  and 
if  the  DSP  coprocessor  board  is  properly  designed,  the  ISA-bus  data-transfer  bottleneck  can  be  elimi¬ 
nated.  Option  2  costs  were  ~$15K. 

Option  3:  X86  +  Vision  Processor  Hardware/Software 

This  option  consists  of  a  host  X86  processor  controlling  a  vision  processor  ISA  bus  adapter  board. 
Like  Option  2,  this  option  requires  two  software  development  environments,  one  for  the  X86  host 
processor  and  one  for  the  vision  processor  chip.  Option  3  is  the  least  flexible  in  terms  of  available 
third-party  COTS  software  libraries  to  leverage  image-processing  task  development.  Any  available 
application  libraries  will  likely  only  be  from  the  vision  processor  chip  vendor.  This  option  represents 
the  highest  risk  for  MPP  development  due  to  the  time  required  to  ramp  up  the  learning  curve  on  pro¬ 
gramming  a  specific  vision  processor  chip.  However,  this  option  provides  the  highest  performance 
solution  for  IP  image-processing  task  development  due  to  the  functional  multiprocessor  design  of  a 
vision  processor  chip.  Option  3  costs  range  from  $47K  to  $100K. 

At  decision  time  in  the  design  of  the  IP,  only  one  vision  processor  product  was  available  on  the 
market,  the  m  VCP.  At  that  time,  m  was  not  willing  to  sell  its  software  development  tools  for 
applications  like  ours  where  OEM  quantities  were  not  involved. 

DEVELOPMENTS  FOR  THE  MPP  IMAGE  PROCESSOR 

The  hardware  bus  architecture  chosen  for  the  MPP  was  the  PC/104  format.  This  architecture  fea¬ 
tures  PC  ISA  bus  compatibility,  low  cost,  low  power,  and  small  form  factor  (3.5”  by  3.5”).  The 
PC/104  architecture  is  targeted  for  the  industrial  embedded  computer  market.  The  PC/104  vendors 
have  taken  advantage  of  the  low-power,  highly  integrated  technology  developments  driven  by  the  PC 
notebook  market.  The  MPP  and  operator  console  represent  an  extendable  and  distributable  system 
(reference  8).  Each  processing  element  can  be  remoted  by  using  tactical  radios,  wireless  Ethernet 
modems,  or  the  Internet.  The  IP  is  one  of  three  independent  PC/104  processing  elements  in  the  MPP. 
These  processors  transfer  data  between  themselves  and  the  operator’s  console  using  the  TCP/IP  pro¬ 
tocol  over  an  ethemet  network  connection. 

What  is  the  IP? 

The  IP  consists  of  a  486  DX4  100-MHz  ISA  bus  CPU  board  stacked  with  three  PC/104  cards:  a 
video  framegrabber,  Ethemet  data  interface,  and  solid-state  disk  (SSD).  The  IP  consumes  12  watts. 
The  IP  is  programmed  in  Microsoft  C  and  uses  MS-DOS  based  software  application  libraries  for 
video  framegrabbing,  image  compression,  and  TCP/IP  network  connectivity.  A  fast  processor  is 
needed  for  computer-intensive,  image-processing  tasks.  During  hardware  selection  for  the  IP,  the 
fastest  PC/104  CPU  board  was  a  50-MHz  486.  This  was  not  deemed  fast  enough  so  an  ISA  bus  486 
DX4  100-MHz  single-board  computer  was  selected.  Today,  this  board  along  with  the  SSD  PC/104 
board,  can  be  replaced  with  a  single  PC/104  CPU  board  without  modification  of  the  software.  Pen¬ 
tium  (3  V)  PC/ 104  CPU  boards  are  projected  to  be  available  in  the  fall  of  1996.  The  current  IP  hard- 
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ware  configuration  could  be  replaced  with  a  three-card  PC/104  stack  consuming  <5  watts  by  the  end 
of  1996.  An  important  feature  of  the  IP  is  its  application  as  a  testbed  for  low-power,  highly  inte¬ 
grated  embedded  image-processing  solutions. 

IP  Image-Processing  Functions 

The  IP  performs  the  image-processing  tasks  of  the  MPP.  These  tasks  include  input  source  selec¬ 
tion  (FLIR/TV),  noise  filtering,  image  enhancement  preprocessing,  video  motion  detection,  image 
compression,  and  video  compression.  These  IP  tasks  are  described  below. 

Input  Source  Selection.  The  IP  selects  between  two  video-input  sensors,  the  FLIR  and  TV  cam¬ 
eras.  The  IP  is  capable  of  selecting  between  six  video  input  signals.  The  IP  can  accept  a  wide  vari¬ 
ety  of  video-input  formats  including  PAL,  NTSC,  and  CCIR  601.  These  video  formats  can  be  inter¬ 
laced  or  noninterlaced.  The  IP  low  pass  filters  the  selected  input  video  and  applies  a  noise-reducing, 
three-tap  digital  FIR  filter. 

Image-Enhancement  Preprocessing.  The  IP  performs  operator-selectable,  image-enhancement 
preprocessing  functions  including  region  of  interest  subimage  selection,  contrast  enhancement,  histo¬ 
gram  equalization,  and  automatic  FLIR  level  and  gain  control. 

The  automatic  FLIR  level  and  gain  control  is  performed  in  conjunction  with  the  payload  processor. 

Video  Motion  Detection.  The  IP  has  simple  video-motion-detection  algorithms.  Successive  image 
frames  are  recaptured  and  subtracted  from  each  other.  Pixel  differences  exceeding  a  deadband  zone 
around  zero  are  binary-thresholded.  The  binary-thresholded  image  frame  is  nonlinearly  processed 
with  a  median  filter  to  reduce  noise  and  enhance  target  pixel  clusters.  The  number  of  target  pixels  is 
compared  against  an  operator-selectable  threshold.  If  the  threshold  is  exceeded  for  a  programmable 
consecutive  number  of  times,  then  a  motion-detection  alert  is  transmitted  to  the  payload  processor. 

Image  Compression.  The  IP  uses  an  MS-DOS  software  compression  library  for  still-image  com¬ 
pression.  The  still-image  compression  algorithm  used  is  JPEG.  This  algorithm  is  freely  available 
from  the  Independent  JPEG  Group  (IJG).  The  operator  selects  the  compression  ratio  used  by  the  IP 
during  image  compression.  The  latest  version  of  IJG  JPEG  supports  progressive  transmission,  which 
when  implemented  in  the  IP,  will  improve  MPP  system  operational  performance  over  tactical  radios. 
Wavelet  algorithms  have  been  purchased  but  not  implemented  in  the  IP.  These  algorithms  offer 
improved  performance  over  JPEG  algorithms  in  areas  of  compressed  image  quality,  progressive 
transmission,  and  differential  area  enhancement. 

Video  Compression.  A  video  compression  algorithm  has  been  developed  and  tested  but  not 
implemented  for  the  IP.  This  was  due  to  the  slow  data-transfer  rate  using  tactical  radios.  The  algo¬ 
rithm  includes  JPEG  compression  for  intraframe  coding.  Interframe  coding  consists  of  frame  differ¬ 
encing  of  decompressed  frames  against  a  decompressed  reference  frame.  The  difference  frame  is 
then  decomposed  into  a  1-bit  position  map  and  an  array  of  difference  pixels.  The  position  map  is 
losslessly  compressed  using  a  Group  4  fax  technique  while  the  pixel  array  is  losslessly  compressed 
using  an  LZW  technique. 

A  video  compression  algorithm  has  recently  been  acquired  for  the  IP  from  the  International  Tele¬ 
communication  Union  (ITU)  Study  Group  15’s  (SG  15)  open  software  web  site.  The  ITU  SG  15 
committee  is  developing  the  next-generation  video-compression  standards  for  the  PTSN  and  the 
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wireless  cellular  markets.  This  algorithm  is  known  as  H.263M  and  is  an  enhancement  of  H.261  used 
in  video  teleconferencing.  H.263M  has  some  error-resilient  features  built  into  the  algorithm  to  com¬ 
bat  the  noisy  channels  found  in  the  mobile  cellular  world.  This  algorithm  is  slated  for  final  standard¬ 
ization  in  late  1996. 

IP  Data  Transfer 

An  important  feature  of  the  IP,  as  well  as  the  other  processors  in  the  MPP,  is  the  use  of  the  TCP/IP 
protocol  and  Ethernet  network  connectivity  as  its  data  communications  mechanism  between  proces¬ 
sing  elements.  Each  processor  uses  a  state  machine  to  determine  who  it  is  connected  to  on  the  net¬ 
work  and  how  to  process  its  data  accordingly.  For  example,  if  the  tactical  radio  ethemet  processors 
are  replaced  by  the  Internet  as  the  communications  link  between  MPP  and  operator  console,  the  IP 
will  sense  this  and  transfer  its  data  directly  to  the  operator’s  console  computer.  Depending  on  con¬ 
nected  processing  elements,  the  IP  can  work  directly  with  the  operator  console  computer  or  through 
the  payload  and  radio  processors. 

IP  Issues 

During  MPP  field  tests,  it  was  determined  the  the  IP  video  framegrabber  did  not  work  properly 
with  the  Inframetric’s  Infracam  FLIR  camera.  This  was  due  to  the  noninterlace  NTSC  format  of  the 
FLIR’s  video  output  signal  and  the  inability  of  the  IP  framegrabber  to  handle  this  signal  correctly.  A 
new  framegrabber  with  software  library  was  purchased  that  could  handle  the  noninterlace  video  for¬ 
mat.  This  new  framegrabber  and  software  were  integrated  into  the  IP  in  less  than  a  month. 

Video-compression  algorithms  have  been  tested  but  not  implemented  in  the  IP  hardware.  The  tac¬ 
tical  radio  link  operates  too  slowly  for  video  compression  to  work  effectively.  The  radio  protocol  at 
present  is  not  appropriate  for  video  data  streaming.  Long  delays  were  observed  in  data  transfers  due 
to  ACK/NACKs  that  would  greatly  inhibit  temporal  redundancy  reduction  algorithms  used  in  video 
compression.  A  different  radio  protocol  is  needed  for  video  compression  to  work  effectively  over 
tactical  radios. 

A  PC/104  framegrabber  board  with  DSP  was  purchased  for  the  IP  with  the  hopes  of  improving  IP 
image-processing  performance.  This  product  came  with  JPEG  compression  software  written  for  the 
DSP;  however,  this  algorithm  ran  slower  than  the  486-hosted  JPEG  algorithm  we  were  currently 
using.  The  main  reason  for  this  was  due  to  Umited  memory  available  for  processing  on  the  PC/104 
board  and  part  of  the  JPEG  algorithm  being  hosted  on  the  PC  host  processor  board.  It  is  hoped  that 
fumre  products  of  this  kind  will  fix  these  problems,  thereby  providing  an  improvement  in  IP  image- 
processing  performance. 

CONCLUSIONS 

The  AMGSSS  image-processing  tasks  have  to  be  combined  into  an  integrated  image-processing 
subsystem.  This  is  the  only  approach  that  will  satisfy  the  very  restrictive  requirements  for  power, 
weight,  and  cost  without  sacrificing  subsystem  performance.  An  integrated  image-processing  sub¬ 
system  is  one  that  incorporates  compression,  video  motion  detection,  terrain  slope  determination,  and 
various  image-enhancement  features.  Any  image-processing  hardware  solution  should  take  advan¬ 
tage  of  recent  developments  in  low-power,  programmable,  multiprocessor  vision  ASICs. 

Image -preprocessing  tasks  should  not  be  underestimated  for  tactical  surveillance  applications  such 
as  AMGSSS.  These  tasks  play  a  vital  role  in  providing  the  essential  surveillance  imagery  data  to  the 
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operator  over  low-bandwidth  LPI/LPD  tactical  radio  links.  Important  tasks  include  global  image  sta¬ 
bilization  of  video  sensor  jitter  induced  by  wind,  image  contrast  enhancement  during  times  of  the  day 
when  surveillance  imagery  has  low  signal  to  noise,  linear  and  nonlinear  image  noise  filtering  tech¬ 
niques,  edge  enhancement  for  aiding  operator  detection  on  manmade  targets,  and  sensor  fusion  to 
increase  target  signal-to-noise  ratios. 

A  videotape  was  developed  for  the  AMGSSS  program.  This  videotape  is  used  to  evaluate  vendor 
image-processing  hardware  and  software  in  performing  AMGSSS  video  surveillance  tasks  in  all 
types  of  weather  and  environmental  conditions  over  the  course  of  a  24-hour  day. 

During  MPP  field  tests  with  SINCGARS  and  PRC- 139  VHP  tactical  radios,  it  was  determined  that 
existing  military  data-transfer  protocols  were  not  appropriate  for  video  streaming  data.  Protocols 
need  to  be  established  for  video  data  streams  that  reduce  the  transmission  delays  between  radio  pack¬ 
ets  that  currently  occur  because  of  data  packet  ACK/NACKs  that  ensure  error-free  transmission. 
Error-free  transmission  techniques  produce  latency  effects  that  reduce  temporal  redundancy,  thereby 
reducing  video-compression  efficiency.  Error-free  transmission  is  not  required  for  video  streaming 
since  data  are  continually  being  updated. 

The  MPP  IP  is  an  example  of  a  low-cost,  low-power  embedded  image-processing  subsystem  for 
surveillance  applications.  It  consists  of  COTS  PC/104  hardware  and  MS-DOS  application  software 
making  it  easily  upgradeable  as  better  commercial  products  become  available.  Examples  of  this 
include  faster  lower  power  CPU  boards,  more  functionally  integrated  PC/104  boards,  and  better 
image-compression  application  software  packages. 

The  IP  uses  the  TCP/IP  protocol  for  its  interprocessor  communication  scheme.  This  method  of 
interprocessor  communications  provides  an  easily  scalable  functional  architecture.  The  IP  is  an  inde¬ 
pendent  processing  element  that  can  function  in  stand  alone  fashion  with  an  operator  control  com¬ 
puter,  or  in  conjunction  with  other  processing  elements  such  as  in  the  MPP. 

As  an  embeddable  image-processing  testbed,  the  IP  is  used  to  investigate  and  develop  robust  algo¬ 
rithms  for  remote  video  surveillance  applications.  These  algorithms  include:  error-resilient  image/ 
video  compression  techniques  for  transmission  over  noisy  rgdio  channels;  image  enhancement  and 
redundancy  reducing  preprocessing  techniques;  and,  robust  video  motion  detection  techniques  for 
noisy  surveillance  scenes.  Currently,  the  IP  software  is  being  sent  to  Sandia  National  Laboratory 
where  video  motion  detection  algorithms  can  be  integrated.  Because  of  the  distributive  feature  of  the 
MPP  system  design,  the  SNL  algorithms  can  be  tested  in  the  MPP  subsystem  over  the  Internet  with 
the  IP  existing  in  Albuquerque,  New  Mexico,  and  the  rest  of  the  MPP  in  San  Diego,  CaUfomia. 

RECOMMENDATIONS 

These  recommendations  fall  into  two  categories:  those  for  the  MPP  IP  and  those  for  the  AMGSSS 
IP.  In  general,  the  AMGSSS  IP  recommendations  include  those  of  the  MPP  IP. 

MPP  IP 

•  Develop  a  new  tactical  radio  data  transfer  protocol  conducive  to  video  streaming. 

•  Implement  H.263M  video-compression  algorithms. 

•  Implement  wavelet  still-image  compression  algorithms. 
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•  Provide  operator-selectable  choice  of  still-image  compression  algorithm  between  JPEG,  pro¬ 
gressive  JPEG,  NITFS  2.0,  wavelets,  and  progressive  wavelets.  This  will  provide  interoper¬ 
ability  when  needed  and  performance  when  not. 

•  Develop  error-resilient  image/video  compression  techniques. 

•  Develop  image-stabilization  algorithms. 

•  Investigate  FLIR/TV  sensor  fusion  algorithms. 

•  Develop  improved  robust  video  motion  detection  algorithms.  This  could  be  facilitated  through 
teaming  with  Sandia  National  Laboratories  and  New  Mexico  State  University. 

•  Upgrade  PC/104  hardware  to  low-power  Pentium  (3-V)  CPU  card  and  more 
advanced  DSP  framegrabber.  This  will  reduce  MPP  IP  size  and  power  while  increasing 
image-processing  performance. 

•  Purchase  vision  processor  chip  and  software  development  tools.  Implement  image-processing 
algorithms  on  vision  processor  chip. 

•  Develop  PC/104  board  with  vision  processor  chip.  This  could  be  accomplished  by 
having  Delta  Information  Systems  downsize  its  Vidicoder  (3”  x  5”)  product. 

AMGSSS  IP 

•  Fund  two  different  approaches  for  developing  an  integrated  image  processor  for 
AMGSSS  that  conforms  to  the  power,  weight,  and  costs  constraints.  A  downsized  version  of 
David  Samoff  Research  Center’s  VFE-100  represents  a  good  choice  for  one  approach.  The 
Delta  Information  System’s  Vidicoder  vision  processor  board  represents  another  good 
approach  for  AMGSSS. 

•  Purchase  the  VFE-100  and  its  software  development  tools  for  AMGSSS  image-processing 
tasks  development. 

•  Generate  a  Broad  Area  Announcement  (BAA)  for  soliciting  proposals  to  develop  slope  deter¬ 
mination  algorithms  for  AMGSSS. 
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APPENDIX  F:  ONBOARD  CONTROLLER 

Doug  Gage 

Control  processing  tasks  onboard  the  MPP  Remote  Platform  are  divided  between  three  processors: 
the  Image  Processor  (IP),  Radio  Computer  (RC),  and  the  Payload  Processor  (PP),  which  intercom¬ 
municate  via  Ethernet  LAN  and  TCP/IP  protocol.  This  partition  of  functionality  is  motivated  by  the 
fact  that  both  the  IP  and  RC  make  heavy  use  of  software  packages  written  by  other  agencies/compa¬ 
nies,  and  this  physical  partitioning  reduces  the  possibility  of  interference  between  “black  box”  soft¬ 
ware  modules,  as  well  as  facilitating  the  simultaneous  development  of  the  separate  processing  sub¬ 
systems.  The  IP  and  RC  are  discussed  at  length  in  appendices  E  and  C  respectively;  this  appendix 
focuses  on  the  PP  software. 

REQUIREMENTS/  BASELINE  DECISIONS 

The  PP  provides  the  remote  user,  through  the  CDC,  with  the  ability  to  control  the  sensor  resources 
onboard  the  RP:  TV  camera,  FLIR  camera,  laser  rangefinder,  Azimuth-Elevation  (Az-El)  mount,  and 
acoustic  sensing  system.  It  does  this  by  accepting  and  executing  user  commands  from  the  CDC, 
returning  system  and  subsystem  status  messages  to  the  CDC,  and  coordinating  the  acquisition  and 
flow  of  image  data  from  the  IP  back  to  the  CDC.  Command  execution  requires  communication  with 
the  sensor  subsystems  via  RS-232  serial  streams  (FLIR,  laser  rangefinder,  pan/tilt,  acoustic  subsys¬ 
tem)  and/or  discrete  signals  (TV  focus  and  zoom)  via  a  relay  board. 

The  PP,  like  the  IP  and  RC,  is  implemented  on  PC- 104  form-factor  processing  boards  using  the 
MS-DOS  operating  system,  reflecting  (1)  the  need  for  high-performance,  compact,  and  low-power 
processing  hardware  capable  of  hosting  the  driver  software  provided  by  the  Az-El  vendor  and  (2)  the 
availability  of  compatible  I/O  hardware  (RS-232  ports,  relays,  Ethernet)  required  to  interface  to  the 
sensor  hardware  and  the  other  subsystems. 

The  PP  software  is  written  in  the  C  language,  for  compatibility  with  the  Az-El  driver  software,  to 
facilitate  the  reuse  of  other  software  modules — such  as  the  serial  and  TCP/IP  Service  packages,  and 
the  Command  Line  Interpreter — previously  written  for  the  MIUW-SU  and  other  NRaD  software 
development  efforts,  and  to  effectively  leverage  project  programmer  skills,  experience,  and  the 
installed  base  of  development  tools. 

OPTIONS  CONSIDERED 

An  alternate  architecture  that  was  considered  was  the  implementation  of  the  onboard  controller  as 
a  network  of  LONWorks  (reference  F-1)  nodes.  LONworks  is  an  architecture,  developed  by  Echelon 
Corporation,  for  distributed  control  networks  (“Local  Operating  Networks”)  of  compact  inexpensive 
controller  nodes,  applicable  to  building  automation  or  to  the  integration  of  complex  systems  such  as 
automobiles.  Each  LONWorks  node  incorporates  an  inexpensive  microcontroller  (manufactured  by 
both  Motorola  and  Toshiba)  called  a  “Neuron”  chip,  which  is  capable  of  handling  many  control 
applications  itself,  and  which  can  also  be  used  as  a  “front  end”  communications  processor  for  sub¬ 
systems  requiring  more  processing  horsepower  than  the  Neuron  can  provide.  LONWorks  provides  a 
fully  developed  seven-layer  protocol  stack  in  which  subsystem  control,  status,  and  data  parameters 
are  represented  as  “network  variables,”  and  the  communication  of  network  variables  between  nodes 
is  completely  transparent  to  the  system  implementer.  Unfortunately,  the  development  of  a  LON- 
Works  system  requires  the  purchase  of  proprietary  development  tools  from  Echelon  at  a  price  that 
was,  until  early  1995,  in  excess  of  $25K,  so  this  option  was  not  pursued.  Nevertheless,  an  internal 
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interface  layer  was  included  in  the  PP  implementation  in  which  sensor  subsystem  parameters  are  rep¬ 
resented  by  data  structures  analogous  to  network  variables,  in  order  to  facilitate  a  future  incremental 
introduction  of  LONWorks  or  similar  technology  into  the  AMGSSS  system. 

REMOTE  PLATFORM  FUNCTIONALITY 

One  key  to  the  successful  implementation  of  a  complex  remotely  controlled  system  is  the  estab¬ 
lishment  of  a  clean  model — precise  yet  intuitive — in  the  minds  of  both  system  users  and  implement- 
ers  for  the  functionality  to  be  provided  to  the  operator’s  station  by  the  system’s  remote  element.  The  . 

protocol  between  remote  vehicle  and  operator  station  is  essentially  that  between  a  server  and  a  client. 

In  the  case  of  the  AMGSSS  MPP,  RP  functionality  is  defined  in  terms  of  a  well-defined  set  of  com¬ 
mands,  which  the  PP  is  prepared  to  accept  and  execute.  ^ 

High-Level  (View)  Commands 

The  MPP  operator  at  the  CDC  sees  RP  functionality  principally  in  terms  of  images  being  dis¬ 
played  at  the  CDC  after  they  have  been  acquired  and  transmitted  by  the  RP.  The  CDC  passes  an 
image  specification  (or  view)  to  the  RP,  and  the  RP  acquires  and  returns  the  image  as  soon  as  it  can. 

A  view  specifies:  the  direction  the  Az-El  mount  is  to  point,  whether  the  TV  or  the  FLIR  camera  is  to 
be  used,  how  the  camera  is  to  be  configured  (focus  and  zoom  values  for  TV;  image  polarity,  level 
and  gain  for  FLIR),  and  how  the  acquired  image  is  to  be  processed  by  the  IP  (cropping,  image  com¬ 
pression  ratio). 

Alert  Response  Specification 

The  MPP  has  two  capabilities  for  explicitly  detecting  potential  threats.  The  acoustic  detection  sub¬ 
system  sends  the  PP  a  report  of  acoustic  detections  every  1.25  seconds,  each  acoustic  source  being 
labeled  with  its  azimuth  from  the  MPP;  its  type  (ground  vehicle,  propeller  aircraft,  jet,  aircraft,  heli¬ 
copter;  or  unknown);  and  a  measure  of  the  acoustic  subsystem’s  confidence  in  the  detection.  The 
CDC  operator  can  install  filters  in  the  PP  to  specify  which  acoustic  detections  will  be  forwarded  to 
the  CDC,  and  also  specify  whether  to  automatically  return  an  image  and/or  a  laser  range.  The  IP’s 
motion  detection  function  is  invoked  with  a  view  command,  and  the  operator  can  also  specify 
whether  to  automatically  return  an  image  and/or  a  laser  range  when  motion  is  detected. 

Low-Level  Commands 

An  extensive  set  of  low-level  commands  allows  the  user  more  detailed  control  of  the  RP’s  subsys¬ 
tems,  e.g.,  set  the  Az-El  azimuth  to  -30  degrees,  set  the  TV  zoom  to  20,  increase  the  FLIR  gain  by 
35.  These  commands  are  intended  to  support  system  integration  and  debugging,  and  troubleshooting 
in  the  field. 

Command  Programs 

Both  high-level  and  low-level  commands  can  be  strung  together  in  command  programs  up  to  „ 

hundreds  of  steps  long.  Programs  are  usually  used  to  acquire  a  panorama  of  images,  or  to  repeatedly 
(via  the  special  command  REPEAT)  scan  a  number  of  potential  threat  directions  with  motion  detec¬ 
tion.  Programs  are  downloaded  from  the  CDC  and  can  also  be  uploaded  back  to  the  CDC  for  inspec¬ 
tion  and  validation.  The  PP  can  store  three  programs,  but  only  one  program  can  be  executing  at  any 
one  time;  the  operator  controls  program  execution  with  the  PP  commands  RUN,  HALT,  and  CON¬ 
TINUE. 
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PP  SOFTWARE  IMPLEMENTATION 


Command  Execution  Process 

Many  RP  subsystem  functions  take  a  very  long  time  when  measured  in  terms  of  processor  execu¬ 
tion  cycles.  For  example,  a  full  pan  excursion  of  the  Az-El  takes  almost  2  seconds;  a  full  range  cam¬ 
era  lens  zoom  excursion  takes  6  seconds;  and  the  FLIR  takes  several  minutes  to  initially  cool  to  its 
operating  temperature.  Hence  the  PP  software  must  be  written  so  that  long-duration  commands  do 
not  tie  up  the  PP’s  CPU,  which  is  running  plain  old  single-threaded  DOS  as  its  “operating  system.” 
Moreover,  operations  of  different  subsystems  must  be  allowed  to  overlap,  so  that  the  Az-El  can  be 
panning  while  the  camera  lens  is  zooming  and  so  forth.  On  the  other  hand,  high-level  view  com¬ 
mands  require  that  subsystem  operations  be  properly  sequenced  to  succeed.  For  example,  in 
response  to  a  view  command,  the  PP  must  be  able  to  command  the  Az-El  to  its  new  position  and 
then  immediately  command  the  camera  zoom  and  focus  to  their  new  values.  When  both  operations 
have  completed,  the  PP  must  wait  an  additional  2  seconds  for  the  camera  auto-iris  to  stabilize,  and 
only  then  command  the  image  processor  to  grab  and  process  the  image. 

To  support  this  flexibility  of  operation,  a  resource  lock  mechanism  has  been  implemented  that  per¬ 
mits  the  simultaneous  execution  of  multiple  commands  not  requiring  the  same  resources,  while  forc¬ 
ing  commands  that  require  resources  already  in  use  to  wait  until  those  resources  become  free. 
Resource  granularity  is  at  the  subsystem  level,  i.e.,  pan/tilt,  TV,  FLIR,  laser  rangefinder,  and  image 
processor. 

The  command  execution  process  involves  two  levels  of  procedure  calls,  each  involving  a  state 
machine.  When  the  resources  required  for  a  command’s  execution  become  available,  the  ExecCmd 
procedure  is  called  with  the  command’s  op-code  and  parameters  (e.g.,  view  data  structure),  and  ini¬ 
tial  state  (cmd->state)  equal  to  1.  ExecCmd,  after  marking  the  resources  it  is  using  as  busy,  generally 
invokes  a  subsystem-specific  process,  communicating  the  required  actions  via  variables  analogous  to 
LONWorks  network  variables.  For  example,  if  the  camera  zoom  is  to  be  increased  by  20,  then 
ExecCmd  sets  the  desired  zoom  value  (vis.newZoom)  to  20  plus  the  current  zoom  value 
(visS->zoom),  then  sets  the  state  variable  (vis.state)  for  the  camera  specific  process  (VisProc)  to  1, 
gives  VisProc  a  pointer  to  this  command  (vis.cmd),  sets  its  own  cmd->state  to  2,  and  returns. 

VisProc  is  called  on  every  pass  through  the  main  program  loop,  but  returns  immediately  if  vis.state 
equals  0  or  9.  When  vis.state  is  1,  however,  VisProc  sets  a  timer  that  closes  the  zoom-in  or  zoom-out 
relay  for  the  required  time,  sets  vis.state  equal  2,  then  returns.  When  VisProc  is  called  with  vis.state 
=  2,  it  returns  immediately  if  the  zoom  timer  is  non-zero  (i.e.,  if  the  relay  is  still  closed);  when  the 
timer  has  finally  timed  out,  VisProc  sets  visS->zoom  equal  to  vis.newZoom,  sets  vis.state  to  0,  and 
calls  ExecCmd  again. 

ExecCmd  now  sees  that  cmd->state  =  2,  and,  if  this  is  a  simple  command  to  change  zoom,  it  pro¬ 
ceeds  to  clean  up  by  setting  vis.state  =  0,  marking  its  resources  as  not  busy,  and  setting  cmd->state  = 
0;  then  it  returns.  On  the  other  hand,  if  this  is  part  of  a  more  complex  command  involving  an  image 
capture,  then  ExecCmd  can  delay  the  VisProc  cleanup  in  order  to  prevent  another  command  from 
changing  the  camera  settings  before  the  IP  has  captured  the  image. 

Separate  procedures  are  called  each  program  loop  for  the  Az-El,  FLIR,  camera  (vis),  laser  range¬ 
finder,  and  image  processor  resources. 
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Coordination  of  Image  Transfer  with  image  Processor  and  Radio  Computer 

An  extension  of  this  simple  state  machine  concept  to  multiple  processors  provides  floM'  control  for 
the  transfer  of  (potentially)  large  image  files  from  the  IP  to  the  RC,  and  thence  via  the  radio  channel 
to  the  CD.  The  IP  is  one  of  the  resources  used  by  PP  commands,  and  a  PP  process  ImageProc  is 
called  much  like  VisProc  as  described  above.  The  PP  sends  a  command  message  to  the  IP  to  acquire 
an  image,  and  marks  the  IP  as  busy  until  the  IP  acknowledges  that  it  is  ready  to  take  another  image. 
The  IP,  however,  does  not  send  this  acknowledgment  until  it  has  successfully  transferred  the  image 
to  the  RC  and  received  a  reply  confirming  that  the  RC  is  ready  to  accept  another  image  file.  Hence, 
when  the  PP  is  executing  a  program  to  take  a  sequence  of  images  (e.g.,  a  panorama),  images  are 
taken  in  rapid  succession  until  the  RC’s  buffers  can  no  longer  accommodate  another  maximum-sized 
image,  whereupon  the  RC  delays  its  acknowledgment  to  the  IP  until  enough  buffer  space  has  been 
freed  by  successfully  acknowledged  transmission  over  the  radio  channel  to  the  CD. 

Command  Sources 

The  main  loop  of  the  PP  software  attempts  to  execute  commands  from  a  number  of  different 
sources,  in  round-robin  sequence: 

•  If  a  message  containing  a  command  has  been  received  from  the  CD  or  one  of  the  other  sources 
discussed  below,  then,  if  all  resources  required  to  execute  the  command  are  available,  the  com¬ 
mand  is  executed;  if  any  required  resource  is  busy,  then  the  command  is  placed  on  the  tail  of 
the  command  queue. 

•  If  the  command  queue  is  not  empty  and  if  all  resources  required  to  execute  the  command  at  the 
head  of  the  queue  are  available,  that  command  is  removed  from  the  queue  and  is  executed; 
otherwise  the  queue  is  left  unchanged.  This  scheme  ensures  that  commands  in  the  queue  are 
executed  in  the  order  in  which  they  were  queued,  but  also  means  that  a  command  waiting  for  a 
busy  resource  can  block  the  execution  of  other  commands  whose  required  resources  are  avail¬ 
able. 

•  If  a  command  program  is  running  (active)  and  if  all  resources  required  to  execute  the  next 
command  step  of  the  active  program  are  available,  that  command  is  executed  and  the  program 
pointer  is  incremented  to  point  to  the  next  step;  otherwise  no  action  is  taken.  If  the  next  com¬ 
mand  is  a  NOOP,  the  pointer  is  incremented  again;  if  it  is  REPEAT,  the  pointer  is  reset  to  the 
first  step  of  the  program. 
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This  conunand  flow  is  depicted  in  figure  F-1. 


DEBUG  LAPTOP(S)  CONTROL  DISPLAY  (CD) 


Figure  F-1.  Command  flow. 


Command  Line  Interpreter  (CLI) 

To  support  system  troubleshooting  and  maintenance  in  the  field  as  well  as  debugging  during  sys¬ 
tem  development  and  integration,  the  PP  incorporates  a  Command  Line  Interpreter  (CLI)  to  allow  a 
user  to  quickly  and  concisely  interact  with  the  PP  at  the  subsystem  level.  This  CLI  software  has 
been  evolved  over  about  15  years,  and  has  been  used  in  many  projects  implemented  on  computer 
platforms  ranging  from  the  Commodore  PET  and  simple  8-bit  microcontrollers  to  the  PC,  Macin¬ 
tosh,  and  Sun  Workstation.  The  CLI  has  the  following  features. 

For  ease  of  remembering,  commands  are  sequences  of  words,  plus  optional  parameters.  The  syn¬ 
tax  chosen  for  the  PP  is  <subsystem  name>  <parameter  name>  <action>  (omission  of  <action> 
implies  “show  current  value”)-  So  the  following  are  valid  PP  commands: 

(show  current  value  of  camera’s  zoom  variable) 

(set  camera  zoom  value  to  33) 

(increment  camera  zoom  by  VIS  Zoom  Delta) 

(show  current  value  of  camera  zoom  increment  variable) 

(set  camera  zoom  increment  variable  to  8) 

(set  FLIR  gain  variable  to  320) 

(command  Az-El  mount  to  move  to  0,0  home  position) 

(command  rangefinder  to  return  values  in  meters,  vice  yards) 

(show  list  of  queued  commands) 


VIS  Zoom  <cr> 

VIS  Zoom  =  33  <cr> 

VIS  Zoom  + 

VIS  Zoom  Delta  <cr> 
VIS  Zoom  Delta  =  8<cr> 
FLIR  Gain  =  320<cr> 
Pan/Tilt  Center<cr> 
Laser  Units  Meters<cr> 
Software  Queue  Display 
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For  ease  of  command  entry,  the  user  types  only  the  first  character  of  a  command  word,  and  the 
CLI  echoes  the  entire  command  word.  Actually,  the  programmer  can  choose  almost  any  character  to 
trigger  a  given  command,  so  in  fact  the  user  types  “SXK<cr>”  to  enter  the  command: 

Software  eXecuting-Commands  Kill<cr>  (kills  all  commands  currently  executing) 

Typing  <del>  while  entering  a  command  erases  the  last  command  word  (or  the  last  character  of  a 
parameter  string  being  entered). 

Typing  “>”  while  entering  a  command  “remembers”  the  command  words  already  entered,  so  that, 
for  example,  the  user  can  easily  focus  on  one  subsystem,  and  this  mode  is  reflected  in  the  CLI 
prompt,  which  displays  the  remembered  words  before  the  prompt  “>”.  If,  for  example,  the  user 
wanted  to  repeatedly  increment  the  FLIR  gain  while  looking  at  an  attached  monitor,  he  could  enter 
“FG>”  and  then  would  have  to  type  only  “+”  instead  of  “FG+”  each  time.  Typing  “<”  erases  the  last 
remembered  word,  moving  the  prompt  to  the  left. 

The  user  can  type  ?  while  entering  a  command  to  see  the  command  options  currently  available. 

For  example,  if  the  user  types  “FD?”  the  screen  displays: 

>FLIR  Display-polarity 
White-hot 
Black-hot 

>FLIR  Display-polarity 

The  command  Help<cr>  toggles  the  CLI  between  this  basic  level  of  prompting  and  a  second,  more 
complete  level.  After  executing  Help<cr>,  the  same  entry  of  “FD?”  yields: 

>FLIR  Display-polarity 

White-hot  use  White  to  indicate  hot 

Black-hot  use  Black  to  indicate  hot 

>FLIR  Display-polarity 

The  CLI  command  set  itself  is  defined  by  a  single  data  structure,  so  implementing  the  conunand 
set  for  a  new  application  requires  changes  only  to  the  data,  not  the  C  code.  The  data  structure  speci¬ 
fies  the  command  set  structure  (what  command  words  are  active  at  any  point  in  the  entry  process), 
and,  for  each  command,  the  character  that  must  be  typed,  the  command  word  for  display,  and  the 
“help  enabled”  prompt  string. 

The  CLI  is  written  in  ANSI  C  and  uses  only  standard  console  I/O,  to  make  it  extremely  portable. 

In  addition  to  the  CLI  hosted  on  the  PP  itself,  CLIs  on  other  laptop  computers  can  interact  with  the 
PP  via  messages  exchanged  over  the  Ethernet  or  a  serial  port  (in  the  current  implementation,  a  debug 
computer  can  be  connected  to  the  PP  via  the  serial  port  that  normally  handles  the  acoustic  detection 
system).  Multiple  CLIs  can  interact  with  the  PP  simultaneously,  so  that,  for  example,  one  operator 
can  troubleshoot  the  FLIR  while  a  second  operator  reconfigures  the  laser  rangefinder.  While  the 
human  operators  must  currently  explicitly  coordinate  their  activities  to  avoid  interfering  with  each 
other,  a  “session  layer”  protocol  based  on  the  resource  lock  mechanisms  described  above  could  eas¬ 
ily  be  implemented  to  prevent  such  interference  but  allow  control  of  individual  subsystem  resources 
to  be  passed  between  multiple  users.  This  same  session  layer  mechanism  will  also  support  the 
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orderly  transfer  of  control  of  the  entire  remote  vehicle  from  one  control  station  to  another,  should 
that  be  desired. 

Log  Messages 

A  PP  procedure  named  Log  (not  to  be  confused  with  the  C  function  log,  which  computes  the  natu¬ 
ral  logarithm)  is  provided  to  allow  the  PP  software  coder  to  sprinkle  the  code  liberally  with  debug 
statements  written  using  familiar  printf  format  conversion  specifications,  while  at  the  same  time 
allowing  the  PP  user  to  decide  on  the  fly  which  classes  of  Log  messages  to  actually  see  and  where  to 
see  them.  Log  messages  are  automatically  timestamped,  and  can  be  written  to  a  file  to  create  a 
detailed  timeline  of  system  activity.  The  programmer  associates  one  bit  of  the  Log  function’s  yZag 
argument  to  each  of  a  number  of  debug  message  categories: 

1  subsystem  procedure  activity 

2  command  execution  activity 

4  non-status  message  traffic 

8  buffer  activity  internal  to  the  messaging  process 

16  status  message  traffic  (usually  not  of  interest  in  debugging) 

32  acoustic  subsystem  detections  and  acoustic  simulator 
512  software  error  condition 

A  call  to  the  Log  function  actually  produces  the  Log  message  only  if  the  bitwise  AND  of  the  flag 
argument  and  the  PP  global  variable  logFlag  is  nonzero;  otherwise,  it  immediately  returns.  The  CLI 
command  Software  Logflag  =  <value>  <cr>  allows  the  PP  user  to  see  any  desired  subset  of  the  mes¬ 
sage  categories. 

CONCLUSIONS  AND  RECOMMENDATIONS 

The  AMGSSS  MPP  Remote  Platform’s  onboard  controller,  with  the  Payload  Processor  (PP)  as  its 
core,  implements  a  well-defined  “server”  functionality,  executing  commands  it  receives  from  the  CD, 
and  (especially  for  debugging  purposes)  from  other  clients,  including  the  PP’s  own  Command  Line 
Interface  (CLI).  Mechanisms  implemented  on  the  PP  support  debugging  as  well  as  operational 
requirements,  and  have  been  designed  to  easily  accommodate  the  integration  of  additional  or 
enhanced  sensor  subsystem  components. 

Recommendations  for  future  development  of  the  onboard  controller  are: 

Enhanced  Robustness  for  Subsystem  Control 

The  PP  communicates  via  RS-232  links  with  microcontrollers  embedded  within  several  COTS 
subsystems:  pan/tilt  unit,  FLIR,  laser  rangefinder,  and  acoustic  detection  system.  These  microcon¬ 
trollers  maintain  internal  state  information  that  should  be  “mirrored”  by  the  subsystem  state  informa¬ 
tion  held  by  the  PP  itself.  Error  conditions  or  other  events  of  interest  internal  to  the  subsystems, 
however,  may  not  be  adequately  reported  to  or  detected  by  the  PP.  The  PP  should  be  enhanced  to 
deal  with  these  situations  more  robustly.  Specifically, 
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•  The  low-level  C  code  controlling  the  pan/tilt  unit  should  be  reviewed,  cleaned  up,  and  made 
much  more  “bullet  proof,”  since  what  currently  exists  is  basically  a  quick-and-dirty  encapsula¬ 
tion  of  core  procedures  from  TRC’s  pan/tilt  demonstration  program. 

•  Additional  error  checks  should  be  inserted  into  the  low-level  code  interfacing  with  the  FLIR 
and  laser  rangefinder. 

•  Opportunities  for  the  insertion  of  LONWorks  technology  into  the  onboard  controller  should  be 
reassessed,  since  development  tools  are  now  available  in-house. 

Enhancement  of  Message  Addressing 

The  message-addressing  scheme  used  in  AMGSSS  should  be  refined  to  incorporate  process  ID 
within  the  platform  or  CD  as  well  as  platform  ED.  The  TCP/IP  “service”  model  now  employed 
should  be  replaced  by  a  UDP  messaging  scheme  incorporating  explicit  source  and  destination 
addresses.  This  will  support  flexible  operation  and  debugging  activities  in  an  environment  including 
both  multiple  AMGSSS  vehicles  and  multiple  CDs. 

It  should  be  kept  in  mind,  however,  that  the  most  critical  current  deficiencies  in  the  AMGSSS 
MPP  systems  involve  the  tactical  radio  link  and  its  controller,  and  not  the  onboard  controller  per  se. 
Moreover,  once  the  radio  link’s  performance  has  been  optimized,  it  is  almost  certain  that  the  details 
of  the  CD’s  operator  interface  will  become  the  focus  of  management  attention.  Nevertheless,  the 
above  recommendations  related  to  the  onboard  controller  should  be  pursued  if  the  AMGSSS  project 
is  to  proceed. 
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APPENDIX  G:  CONTROL  DISPLAY  CENTER 

Hoa  Nguyen  and  Bill  Marsh 

OVERVIEW  AND  FUNCTIONAL  REQUIREMENTS 

Figure  G-1  shows  the  AMGSSS  Mission  Payload  Prototype  (MPP)  system  functional  diagram, 
showing  connections  between  the  subsystem  computers.  There  are  two  computers  at  the  control  end 
(a  laptop  running  the  control  display  and  optional  payload  simulator,  and  a  tactical  radio/Ethemet 
modem),  and  three  computers  on  the  remote  payload  side  (payload  processor,  image  processor,  and 
tactical  radio/Ethemet  modem).  Interprocessor  communications  are  via  TCP/IP  using  Ethernet 
cables  and  tactical-radio-frequency  modems. 


- ►  Ethernet  TCP/IP  connections  (from  client  to  host) 

-  -  -  TCP/IP  connections  when  radio  modems  are  off 

a 

— ►  Other  digital  connections 

Figure  G-1.  AMGSSS  MPP  system. 

Functional  requirements  for  the  AMGSSS  Mission  Payload  Prototype  Control  Display  Station 
include: 

•  Portability,  for  ease  of  concept  demonstration. 

•  User-friendly  control  and  display  operations. 

•  Easily  scalable  architecture 

•  Ethernet  TCP/IP  connectivity 

•  Displays  256  colors,  with  capability  for  video  streaming 

To  meet  these  objectives,  we  selected  an  IBM  ThinkPad  755  CD  laptop  computer  (with  a 
100-MHz  80486  processor)  for  control  display  functions.  It  has  256-color  active  matrix  display, 
a  docking  station  for  functional  scalability,  provides  Ethernet  connectivity  via  a  PC-Card  plug-in 
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module,  and  has  built-in  video  display  functions  (this  last  feature  may  be  used  for  video  streaming  in 
the  future,  but  currently  is  not  utilized).  A  PC- 104  single-board  computer  provided  the  Ethemet-to- 
radio  modem  functions  (reference  G-1),  and  is  packaged  together  with  a  hand-held  field  radio  in  a 
RF-shielded  package,  as  shown  in  figure  G-2. 


Figure  G-2.  MPP  control  display  station. 


The  system  employs  a  message-passing  distributed  processing  architecture.  Messages  and  com¬ 
mands  are  passed  between  the  subsystems  via  the  Ethernet  cables  and  via  the  radio  link  between  the 
control  and  payload  ends.  Each  computer  has  an  Internet  (IP)  address  and  uses  a  hosts  data  file 
(“hosts.dat”)  to  find  the  Internet  addresses  of  the  other  modules.  The  network  protocol  is  set  up  to 
automatically  switch  to  an  all-direct  Ethernet  configuration,  by-passing  the  radios,  upon  detecting  the 
absence  of  the  radio  modems.  This  was  intended  as  an  early  developmental  configuration,  but 
proved  very  useful  throughout  the  developmental  cycle  and  later  as  a  valuable  demonstration  tool. 

TCP/IP  and  message-passing  distributed  processing  also  allows  subsystems  to  be  added  with  ease. 
A  new  subsystem  component  would  only  require  an  additional  item  in  the  hosts  data  table,  and  per¬ 
haps  additional  messages  defined  for  the  specific  new  subsystem.  No  hardware  changes  to  the  exist¬ 
ing  subsystems  are  required.  Subsystem  substitutions  are  also  easily  accomplished  by  changing  the 
TCP/IP  addresses  in  the  hosts  data  table.  We  added  a  payload  simulator  late  in  the  development 
cycle  to  help  debug  the  control  display  software  before  the  payload  was  completed,  with  no  changes 
to  existing  hardware  or  software  (reference  G-2). 

CONTROL  DISPLAY  SOFTWARE  ENVIRONMENT 

Both  the  control  display  program  and  the  payload  simulator  program  operate  under  the  Microsoft 
Windows  Graphic  User  Interface  (developed  under  Windows  3.1,  although  they  also  work  under 
Windows  95).  Both  were  developed  using  the  Microsoft  Visual  C++  compiler.  The  Microsoft 
Foundation  Class  library  was  used  to  provide  the  basis  for  object-oriented  programming.  We  used 
Trumpet  Winsock  2.0  to  provide  the  TCP/IP  interface  under  Windows  3.1  (Windows  95  provides  its 
own  TCP/IP  driver). 


G-2 


CONTROL  DISPLAY  PROGRAM 


Figure  G-3  shows  the  top-level  functional  breakdown  of  the  control  display  program.  At  the  heart 
of  the  program  is  the  database  (“document”  in  Visual  C-t-t-  lingo),  containing  information  about 
images  collected,  status  of  all  sensors  and  subsystems,  maps,  and  alerts  received.  The  database  sup¬ 
ports  three  “views”;  the  status  view  with  status  of  all  three  AMGSSS  remote  payloads  (although 
only  one  payload  has  been  developed  for  this  demonstration);  the  geographic  view  with  sensor 
information  overlaid  on  top  of  a  map  of  the  operational  area;  and  the  situation  view,  which  gives  the 
operator  a  “big  picture”  of  how  all  the  images  collected,  programmed  motion  and  acoustic  scanning 
programs,  and  alerts  that  have  come  in  are  interrelated.  In  addition,  there  are  two  independent  win¬ 
dows  (displaying  the  panorama  scene  and  any  high-resolution  snap  shot)  that  can  be  displayed  on  top 
of  any  view.  Communications  between  the  database  and  the  views  are  through  Windows  message¬ 
handling  mechanisms. 


Figure  G-3.  Control  display  program  functional  breakdown. 


The  Status  View 

The  status  view  is  a  text  screen  providing  status  information  on  all  subsystems,  sensors,  and  radio 
links  (see  figure  G-4).  Status  displays  for  three  MPPs  are  available,  although  only  one  is  active  due 
to  the  availability  of  only  one  MPP.  Status  messages  on  the  radio  link  are  provided  by  the  radio  com¬ 
puters  (to  the  control  display  computer  on  the  control  side,  and  to  the  payload  processor  on  the 
remote  side)  every  10  seconds.  The  payload  processor  assembles  all  sensor  and  remote  subsystem 
status  messages  and  forwards  them  over  the  radio  link  to  the  control  display  every  30  seconds.  In 
addition  to  the  information  presented  by  the  status  view,  a  green  status  light  in  the  upper  left-hand 
comer  of  all  views  acts  as  the  system’s  heartbeat.  It  blinks  every  time  a  message  comes  over  the 
radio  link  and  becomes  gray  if  the  link  is  down.  This  enables  the  operator  to  monitor  the  overall  sys¬ 
tem  status  even  when  the  display  is  showing  the  geographic  or  situation  view. 
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Figure  G-4.  Control  display  status  view. 


The  Geographic  View 

The  geographic  view  revolves  around  a  map  of  the  operational  area.  Initially,  we  used  a  vector 
map  to  allow  display  at  multiple  scales.  However,  we  found  that  the  vector  maps  we  could  find  (in 
this  case,  the  Central  Intelligence  Agency’s  World  Database  maps)  were  of  insufficient  detail.  So  we 
switched  to  multi-resolution  scanned  raster  topological  maps.  Figure  G-5  is  a  screen  capture  of  the 
geographic  view  showing  the  topological  map,  overlaid  laser  ranging  results  (the  lines  ending  in 
stars — clicking  on  the  stars  brings  up  a  box  with  range,  time,  and  azimuth  and  elevation  informa¬ 
tion),  motion  alert  (the  triangle),  and  visual  angle  of  displayed  images  (the  shaded  wedge  corre¬ 
sponds  to  the  center  image  in  the  panorama).  The  panorama  images  are  not  part  of  the  geographic 
view  itself  and  can  be  pulled  up  on  any  of  the  three  views.  All  screens  and  operational  images 
showed  here  have  been  obtained  during  a  system  operational  test  at  Mission  Trails  Regional  Park  in 
San  Diego,  California,  in  late  October  1995. 

The  Situation  View 

The  main  function  of  the  situation  view  is  to  present  a  clear  picture  of  the  relationships  between  all 
collected  images,  planned  panorama  and  motion  scans,  laser  ranges  and  alerts  currently  in  the  system 
database.  The  view  is  laid  out  as  three  concentric  rings  representing  +45  degrees,  0,  and  -45  degrees 
in  elevation.  Superimposed  on  these  rings  are  wedge  sections  correlating  to  images  collected  or 
scans  to  be  executed.  Figure  G-6  shows  two  rings  of  panorama  images  (overlapping  in  elevation), 
the  lighter  box  on  the  inner  ring  corresponds  to  the  center  pane  in  the  panorama  image  strip  above. 
The  operator  can  select  the  amount  of  information  to  be  displayed  on  the  view  by  clicking  on  the 
items  listed  at  the  lower  left  comer  of  the  screen. 
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Figure  G-5.  Control  display  screen  showing  the  geographic  view  and  panorama  images. 
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Figure  G-6.  Control  display  screen  showing  the  situation  view,  panorama  images, 
and  a  manual  control  dialog  box. 


Programmed  Execution  and  Responses 

Besides  the  capability  for  manual  control  of  the  sensor  package  (figure  G-6  shows  a  typical 
manual  control  dialog  box),  the  AMGSSS  control  display  program  also  offers  several  program 
modes  to  simplify  the  operator’s  workload.  The  operator  can  program  the  system  to  perform  pan¬ 
oramic  sweeps  to  get  a  feel  for  the  general  landscape  (figure  G-6  shows  two  panorama  rings,  at  -3 
and  +5  degrees  in  elevation).  Likewise,  the  system  can  be  programmed  to  look  for  motion  at  certain 
locations  and  at  some  sensitivity,  using  the  visible  or  infrared  camera.  Acoustic  detections  can  also 
be  filtered.  Only  certain  categories  (ground  vehicle,  jet,  propeller  planes,  etc.)  or  all  can  be  passed  to 
the  operator. 

Programmable  responses  to  alerts  include  automatic  capture  and  transmission  of  a  low-  or  high- 
resolution  image,  automatic  range  determination  via  the  laser  rangefinder,  or  a  return  to  manual  con¬ 
trol.  Figure  G-7  shows  a  motion  alert  and  associated  high-resolution  image  showing  a  moving 
HMMWV  on  a  dirt  road. 
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Figure  G-7.  Control  display  screen  showing  motion  detected. 

CONCLUSIONS  AND  RECOMMENDATIONS 

The  eontrol  display  station  has  been  developed  to  meet  the  immediate  needs  of  the  AMGSSS  Mis¬ 
sion  Payload  Prototype.  In  order  to  expand  the  system  to  the  original  AMGSSS  system  objectives 
(references  G-3  through  G-6),  various  changes  will  be  needed.  Among  them  are: 

•  Conversion  to  a  32-bit  operating  system,  such  as  Windows-NT.  The  power  of  a  32-bit  operat¬ 
ing  system  will  be  needed  to  address  the  following  four  issues. 

—  Incorporating  3-D  maps,  such  as  DMA-supplied  DTED  (elevation  data)  and  ADRG 
(raster)  maps.  A  combination  of  maps  such  as  the  two  mentioned  will  be  necessary  to 
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generate  a  3-D  map  of  the  environment  to  enhance  operator  awareness  and  allow  mission 
planning  on  the  control  display  station. 

—  Adding  mission  planning  capabilities.  This  includes  programming  and  supervision  of  the 
flight  and  landing  of  the  air-mobile  platforms. 

—  Expanding  support  to  three  air-mobile  platforms/sensor  suites. 

—  Addition  of  the  video-streaming  capability. 

•  Enhancing  the  user  interface  based  on  feedback  from  operators  during  field  tests. 

REFERENCES 

G-1.  Martin,  B.  and  D.  Bryan.  1995.  “Low-Cost  Miniature  Interface  and  Control  Systems  for  Smart 
Sensors,  Tactical  Radios,  and  Computer  Networks,”  IEEE  Military  Communications  Confer¬ 
ence  (MILCOM  95),  San  Diego,  CA,  Nov.  6-8. 

G-2.  Murphy,  D.  and  J.  Bott.  1995.  “The  Air  Mobile  Ground  Security  and  Surveillance  System,” 
Unmanned  Systems,  Fall. 

G-3.  Nguyen,  H.  G.  1995.  “Air  Mobile  Ground  Security  and  Surveillance  System,”  NRaD  Robotics, 
World  Wide  Web  URL:  http://www.nosc.mil/robots/. 

G-4.  Nguyen,  H.G.,  W.C.  Marsh,  and  D.W.  Bryan.  1996.  “Virtual  Systems:  Aspects  of  the  AMGSSS 
Prototype,”  Unmanned  Systems,  vol.  14,  no.  1,  Winter. 

G-5.  Schneider,  R.  H.,  ed.  1993.  “FY  93  Technical  Summary/Air-Mobile  Ground  Surveillance  Sys¬ 
tem  (AMGSSS)  Project,”  Naval  Command,  Control  and  Ocean  Surveillance  Center  RDT&E 
Division,  Advanced  Systems  Division,  San  Diego,  CA  92152-5001,  December.* 

G-6.  Schneider,  R.H.  1994.  “Control  and  Display  Requirements  for  the  Air-Mobile  Ground  Security 
and  Surveillance  System  (AMGSSS),”  Naval  Command,  Control  and  Ocean  Surveillance  Cen¬ 
ter  RDT&E  Division,  Advanced  Systems  Division,  San  Diego,  CA  92152-5001,  August.* 


*  For  further  information,  contact  the  Adaptive  Systems  Branch,  NCCOSC  RDT&E  Division,  San  Diego,  CA. 


G-7 


REPORT  DOCUMENTATION  PAGE 


Form  Approved 
0MB  No.  0704^01 88 


Public  reporting  burden  for  this  collection  of  information  is  estimated  to  average  1  hour  per  response.  Including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information,  including 
suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  121 5  Jefferson  Davis  Highway,  Suite  1204,  Arlington,  VA  22202-4302, 
and  to  the  Office  of  Management  and  Budget.  Paperwork  Reduction  Project  (0704-0188),  Washington,  DC  20503^ _ 


1.  AGENCY  USE  ONLY  (Leave  blank) 


4.  TITLE  AND  SUBTITLE 


2.  REPORT  DATE 


September  1996 


AIR-MOBILE  GROUND  SECURITY  AND  SURVEILLANCE  SYSTEM 
(AMGSSS)  PROIECT  SUMMARY  REPORT 


6.  AUTHOR(S) 

D.  W.  Murphy,  I.  P.  Bott,  I.  P.  Cycon,  W.  D.  Bryan,  J.  L.  Coleman,  D.  W.  Gage, 
W.  C.  Marsh,  B.  F.  Martin,  H.  G.  Nguyen,  and  R.  Schneider 


7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Naval  Command,  Control  and  Ocean  Surveillance  Center  (NCCOSC) 

RDT&E  Division 

San  Diego,  California  92152-5001 


3.  REPORT  TYPE  AND  DATES  COVERED 

Final:  FY  95  -  FY  96 


5.  FUNDING  NUMBERS 

DSWA(DNA);  MIPR 
96-2102 
WU:  82307 
PSEMO:  MIPR  66041 
PE:  0604322D 
AN:  DN301040 


8.  PERFORMING  ORGANIZATION 
REPORT  NUMBER 

NRaDTD2914 


9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

Defense  Special  Weapons  Agency  (DSWA) 

6801  Telegraph  Road 
Alexandria,  VA  22310-3398 


Physical  Security  Equipment 
Management  Office  (PSEMO) 
ATCOM/ATTN:  AMSAT-I-WTP 
10401  Tooten  Road,  Suite  125 
Fort  Belvoir,  VA  22060-5823 


10.  SPONSORING/MONITORING 
AGENCY  REPORT  NUMBER 


12a.  DISTRIBUTION/AVAILABILITY  STATEMENT 


Approved  for  public  release;  distribution  is  unlimited. 


13.  ABSTRACT  (Maximum  200  words) 


This  document  summarizes  the  Air-Mobile  Ground  Security  and  Surveillance  System  (AMGSSS)  project.  The 
AMGSSS  system  is  designed  to  rapidly  position  remotely  operated  ground  sensors  at  locations  of  operational  interest  and 
to  provide  information  obtained  by  those  sensors  back  to  the  operator. 


14.  SUBJECT  TERMS 


Mission  Area:  Robotics 
ground  surveillance 
mobility 


AMGSSS 
physical  security 


15.  NUMBER  OF  PAGES 


16.  PRICE  CODE 


17.  SECURITY  CLASSIFICATION 
OF  REPORT 


18.  SECURITY  CLASSIFICATION 
OF  THIS  PAGE 


19.  SECURITY  CLASSIFICATION 
OF ABSTRACT 


20.  LIMITATION  OF  ABSTRACT 


UNCLASSIFIED 


UNCLASSIFIED 


UNCLASSIFIED 


SAME  AS  REPORT 


NSN  7540-01-280-5500 


Standard  form  298  (FRONT) 


NSN  7540-01-280-5500 


Standard  form  298  (BACK) 


INITIAL  DISTRIBUTION 


Code  D0012 

Patent  Counsel 

(1) 

Code  D0271 

Archive/Stock 

(6) 

Code  D0274 

Library 

(2) 

Code  D0271 

D.  Richter 

(1) 

Code  D02 

H.  Porter 

(1) 

Code D 15 

MAJ  R.  Williamson,  USMC 

(1) 

Code  D30 

F.  Gordon 

(1) 

CodeD371 

J.  Bott 

(3) 

Code  D44204 

R.  Zebuda 

(1) 

Code  D74 

C.  Keeney 

(1) 

Code  D7502 

G.  Dobson 

(1) 

Code  D8405 

J.  Mantione 

(1) 

Defense  Technical  Information  Center 

Fort  Belvoir,  VA  22060-6218  (4) 


NCCOSC  Washington  Liaison  Office 
Washington,  DC  20363-5100 

Center  for  Naval  Analyses 
Alexandria,  VA  22302-0268 

Navy  Acquisition,  Research  and  Development 
Information  Center  (NARDIC) 

Arlington,  VA  22244-5114 

GIDEP  Operations  Center 
Corona,  CA  91718-8000 


Office  of  Undersecretary  of  Defense 
Washington,  DC  20301-3100 

Defense  Special  Weapons  Agency 
Alexandria,  VA  22310-3398  (4) 


Vitro  Corporation 
Langhome,  PA  19047 

Computer  Sciences  Corporation 
Springfield,  VA  22150 

U.S.  Army  Military  Police  School 

Fort  McClellan,  AL  36205  (3) 

U.S.  Army  Missile  Command 

Redstone  Arsenal,  AL  35989-5246  (2) 

PEO/CU 

Arlington,  VA  22202-4304 

U.S.  Army  Aviation  and  Troop  Command 
Hampton,  VA  23681-0001 

U.S.  Army  Strategic  Space  Defense  Command 
Huntsville,  AL  35807-3801 

Northrop  Corporation 
Hawthorne,  CA  90251-5032 

U.S.  Coast  Guard  Headquarters 
Washington,  DC  20593-0001 


DASIAC 

Santa  Barbara,  CA  93102 


National  Guard  Bureau 
Washington,  DC  20310 

U.S.  Army  Infantry  Center 
(2)  Fort  Benning,  GA  31905-5400 


Commander 

ATCOM 

Fort  Belvoir,  VA  22060-5823 


(2) 


U.S.  Army  Training  and  Doctrine  Command 
Fort  Monroe,  VA  2365 1-5000  (2) 

Mounted  Maneuver  Battlespace  Battle  Lab 
Fort  Knox,  KY  40121-5000 

U.S.  Army  Field  Artillery  School 
Fort  Sill,  OK  73503-5600 

U.S.  Army  Signal  Center 
Fort  Gordon,  GA  30905 

U.S.  Army  Intelligence  Center  and 
Fort  Huachuca 

Fort  Huachuca,  AZ  85613-6000  (3) 

U.S.  Army  Combined  Armed  Center 
Fort  Levenworth,  KS  66027-5302 

U.S.  Army  Air  Defense  Artillery  School 
Fort  Bliss,  TX  79916-3802 

U.S.  Army  Aviation  Center 
Fort  Rucker,  AL  36362-5000 

U.S.  Army  Chemical  School 
Fort  McClellan,  AL  36205 

Engineer  School  Support  Battle  Lab 
Fort  Leonard  Wood,  MO  65473-6620 

Field  Artillery  School  Battle  Lab  Support 
Element 

Fort  Sill,  OK  73503-5600 

U.S.  Army  Special  Operations  Command 
Fort  Bragg,  NC  28307-5200 

U.S.  Army  Signal  Center  and  Fort  Gordon 
Fort  Gordon,  GA  30905-5000 


Night  Vision  Directorate 
Fort  Belvoir,  VA  22060-5806 

Sikorsky  Aircraft 
Stratford,  CT  06601-1381 

U.S.  Army  Aviation  and  Troop  Command 
Fort  Eustis,  VA  23604-5577 

Naval  Postgraduate  School 
Monterey,  CA  93943 

National  Security  Agency 
Ft.  George  G.  Meade,  MD  20755 

Boeing  Company 
Sunset,  UT  84015 

Boeing  Space  Center 
Kent,  WA  98032 

RST 

Westminster,  MD  21157 

Battelle  Northwest 
Richland,  WA  99352 

Naval  Research  Laboratory 
Washington,  DC  20375-5320 

Conunandant’s  Warfighting  Laboratory 
Quantico,  VA  22134-5069 

Combat  Service  Support  Battle  Lab 
Fort  Lee,  VA  23801-1809 

Planalysis 

San  Diego,  CA  92126-5527 


